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(57) Abstract: In a method of operating an authentication server, where the authentication server is operatively coupled to a network, 
a request to determine whether a person is allowed to play a game on a gaming system may be received from a computer via the 
network. The request may include biometric data associated with the person. The received biometric data may be compared with 
data in a database that includes biometric data of persons allowed to play games on the gaming system. It may be determined whether 
the person is allowed to play a game on the gaming system based on the comparison of the received biometric data with the data in 
the database. A message may be transmitted to the computer via the network that indicates whether the person is allowed to play a 
game on the gaming system. Additionally, it may be determined whether a gaming unit on which the person desires to play a game is 
in a permitted location for playing the game. A message may be transmitted to the computer via the network that indicates whether 
the gaming unit on which the person desires to play a game is in a permitted location. 
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METHODS AND APPARATUS FOR LIMITING ACCESS TO GAMES 
USING BIOMETRIC DATA 

Cross References to Related Applications 
This application is related to commonly owned U.S. Patent Application No. 

5 (Attorney Docket No. 29757/P-683A), entitled "Methods and Appai-atus 

for Limiting Access to Games Using Biometric Data," which is hereby incorporated 
by reference herein in its entirety for all purposes. 

Background 

This disclosure is generally related to gaming systems, and more particularly 
10 to gaming systems that employ biometric data to limit access to games. 

U.S. Patent No. 5,265,864 to Dickinson et al. describes a cashless gaming 
system suitable for casinos. A player hands over money and an ID card to a clerk at a 
validation terminal. The clerk stores the ID number and the amount of money in the 
memory of the validation terminal. Then the clerk returns the ID card to the player 

15 foroperatinganyoneof a number of game terminals. The player then selects a game 
terminal which reads the player's ID card, whereupon the cash amount firom the 
validation terminal is downloaded to the selected game terminal and the game 
terminal can then be played. When the player wishes to stop play of the game 
terminal completely, the player actuates a cashout switch of the game terminal. Then, 

20 the player presents the ID card to the clerk at the validation terminal and the 

I 

validation terminal reads the ID card. A ticket showing the card number and the cash 
amount is printed and the player is paid tiie cash amount on the spot. The printed 
ticket may be used for reconciliation. 

Various network gaming systems have been previously described. For 
25 example, U.S. Patent No. 6,280,325 to Fisk discloses a computer network which 
manages multiple simultaneous bingo games having a potentially large number of 
bingo cards. The computers simultaneously and in parallel compare called bingo 
numbers to bingo cards stored in each respective computer and also double-verify 
winning cards. Called numbers may be applicable to one, many, or all of the 
30 simultaneous bingo games, and the games may have different tunes or different rules. 
Bingo cards are distributed in the network in accordance with number of hits needed 
by the cards: "one-away" computers handle bingo cards needing one more hit; "two- 
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away" computers handle cards needing two hits. The computers in the network also 
generate statistics on the progress of bingo cards toward winning patterns. The 
winning pattern for any game can be changed in real-time, as desired to continue 
interest in the game. 

5 U.S. Patent No. 6,264,560 to Goldberg, et al. discloses a game playing method 

and apparatus for automating games such as blackjack, poker, craps, roulette, baccarat 
and pai gow, wherein players may play continuously and asynchronously, and 
information related to advertised items can be exchanged between players and 
advertisers. In one embodiment, each instance of a game is likely unique fix)m all 
10 other current game instances. The games do not require a manual dealer and in one 
embodiment, played in a gaming establishment using low cost gaming stations. The 
system may also be used to play such games on the Latemet or an interactive cable 
television network wherem a game controller communicates with players at network 
nodes in their homes and at their leisure. 

15 U.S. Patent No. 6,183,366 to Goldberg, et al. discloses an information service 

and advertising providing system for presenting interactive information services 
together with interactive advertising on a communications network such as the 
Internet and LANs. The information service may be a game played interactively on 
the network while advertising is communicated between users and an advertising 

20 network node. Users may also be provided with various games and/or game 
tournaments via interactive network communicatioDS. Users may respond to 
advertising while being entertained (e.g., via games), or while interacting with another 
network service. 

Summary of the Disclosure 

25 In one embodiment, an authentication server is provided. The authentication 

server may comprise a network communications circuit for communicatively coupling 
to a network, and a controller that controls the operation of the authentication server, 
the controller including a processor and a memory operatively coupled to ttie 
processor. The controller may be programmed to receive from a computer via the 

30 network a request to determine whether a person is allowed to play a game on a 
gaming system, the request including biometric data associated with the person. The 
controller may also be programmed to compare the received biometric data with data 
in a database that includes biometric data of persons allowed to play games on the 
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gaming system, and to determine whether the person is allowed to play a game on the 
gaming system based on the comparison of the received biometric data with the data 
in the database. The controller additionally may be programmed to transmit a 
message to the computer via the network that indicates whether the person is allowed 
5 to play a game on the gaming system. The controller may be further programmed to 
determine whether a gaming unit on which the person desires to play a game is in a 
permitted location for playing the game, and to transmit a message to the computer 
via the network that indicates whether the gaming unit on which the person desires to 
play a game is in a permitted location. 

10 In another embodiment, a method of operating an authentication server is 

provided, the authentication server operatively coupled to a network. The method 
may include receiving from a computer via the network a request to determine 
whether a person is allowed to play a game on a gaming system, the request including 
biometric data associated with the person, and comparing fee received biometric data 

15 with data in a database that includes biometric data of persons allowed to play games 
on the gaming system. The method additionally may include determining whether the 
person is allowed to play a game on the gaming system based on the comparison of 
the received biometric data with the data in the database, and transmitting a message 
to the computer via the network that indicates whether the person is allowed to play a 

20 game on the gaming system. The method also may include determining whether a 
gaming unit on which the person desires to play a game is in a permitted location for 
playing the game, and transmitting a message to the computer via the network that 
indicates whether the gaming unit on which the person desires to play a game is in a 
permitted location. 

25 In another aspect, a gaming server is provided. The gaming server may 

comprise a network communications circuit that allows data to be communicated 
between the gaming server and a gaming unit when the gaming unit is 
communicatively coupled to the gaming server via a network. The gaming server 
further may comprise a controller that controls the operation of the gaming server, the 

30 controller comprising a processor and a memory operatively coupled to the processor. 
The controller may be programmed to cause first display data to be transmitted to the 
gaming unit via the network commimications circuit, the first display data 
representing a game image relating to a game, the game being playable via the 
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gaming unit that is remote jfrom the gaming server, and to receive, from the gaming 
unit, data associated with a game play selection of a player. The controller 
additionally may be programmed to determine whether to permit the game play 
selection based on biometric data, and to, if the game play selection is permitted, 
5 cause second display data to be transmitted to the gaming unit via the network 
communications circuit, the second display data representing a game outcome image 
relating to the game. 

In yet another embodiment, a method of operating a gaming server is 
provided, the gaming server operatively coupled to a network. The method may 

10 include causing first display data to be transmitted to a gaming unit via the network, 
the first display data representing a game image relating to a game, the game being 
playable via the gaming unit that is remote &om the gaming server, and receiving, 
from the gaming unit, data associated with a game play selection of a player. The 
method may further include determining whether to permit the game play selection 

15 based on biometric data, and if the game play selection is permitted, causing second 
display data to be transmitted to the gaming unit via the network, the second display 
data repres^ting a game outcome image relating to the game. 

Additional aspects of the invention are defined by the claims at the end of this 

patent. 

20 Brief Description of the Drawings 

Various e mbodiments o f t he i nvention a re d escribed i n c onnection w ith the 
drawings, a brief description of which is provided below: 

Fig. 1 is a block diagram of an example gaming system; 

Fig. 2 is a flowchart of an example routine for registering a person to play 
25 games via the gaming system; 

Fig. 3 is a flowchart of an example routine for logging on to the gaming 
system; 

Figs. 4A-4D are block diagrams of example registration units; 

Fig. 5 is a perspective view of one example of a gaming unit; 

30 Fig. 5A is an illustration of one racample of a control panel for the example 

gaming unit illustrated in Fig. 5; 
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Fig. 6 is a block diagram of an example gaming unit; 

Fig. 7 is a block diagram of an example authentication server; 

Fig. 8 is a block diagram of an example website server; 

Fig. 9 is a block diagram of an example gaming server; 

5 Fig. 1 0 is a block diagram of an example network controller; 

Fig. 11 is a flowchart of an example routine for obtaining user data for 
registering with a gaming system; 

Fig. 12 is an illustration of an example registration display that may be 
displayed on one of the registration units; 

10 Fig. 13 is a flowchart of an example routine for obtaining biometric data for 

registration; 

Fig. 14 is a flowchart of an example routine for operating a gaming unit; 

Fig. 15 is a flowchart of an example routine for obtaining user data for 
authenticatmg a user; 

1 5 Fig. 1 6 is a flowchart of an example routine for obtaining location data; 

Fig. 17 is a flowchart of an example routine for registering a user with a 
gaming system; 

Fig. 1 8 i s a flowchart o f a n e xample r outine f or c becking t he 1 ocation o f a 
gaming unit; 

20 Fig. 19 is an illustration of an example routine for checking biometric data of a 

user; 

Fig. 20 is a flowchart of an example routine for operating a website server; 

Fig. 21 is an illustration of an example logon display that may be displayed on 
one of the gaming units; 

25 Fig. 2 2 i s a n i Uustration o f an e xample g ame s election d isplay t hat m ay b e 

displayed on one of the gaming units; 

Fig. 23 is an illustration of an example of a visual display that may be 
displayed during performance of a poker routine; 
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Fig. 24 is a flowchart of an example poker routine; 

Fig. 25 is an illustration of an example of a visual display that may be 
di^layed during performance of a blackjack routine; 

Fig. 26 is a flowchart of an example blackjack routine; 

5 Fig. 27 is an illustration of an example of a visual display that may be 

displayed during performance of a slots routine; 

Fig. 28 is a flowchart of an example slots routine; 

Fig. 29 is an illustration of an example of a visual display that may be 
displayed during performance of a keno routine; 

10 Fig. 30 is a flowchart of an example keno routine; 

Fig. 31 is an illustration of an example of a visual display that may be 
displayed during performance of a bingo routine; and 

Fig. 32 is a flowchart of an example bingo routine. 

Detailed Description of Various Embodiments 
15 Although the following text sets forth a detailed description of numerous 

different embodiments of the invention, it should be understood that the legal scope of 
the invention is defined by tiie words of tiie claims set forth at the end of this patent. 
The detailed description is to be construed as exemplary only and does not describe 
every possible embodiment of the invention since describing every possible 
20 embodiment would be impractical, if not impossible. Numerous alternative 
embodiments c ould b e i mplemented, u sing e ither c uirent t echnology o r technology 
developed after the filing date of this patent, which would still fall within the scope of 
the claims defining the invention. 

It should also be understood that, unless a term is expressly defined in this 

25 patent using the sentence "As used herein, tiie term ' ' is hereby defined to 

mean..." or a similar sentence, there is no intent to limit the meaning of that tenn, 
either e xpressly o r b y i mplication, b eyond i ts p lain o r o rdinary m eaning, and s uch 
term should not be interpreted to be limited in scope based on any statement made in 
any section of this patent (other than the language of the claims). To the extent that 
30 any tenn recited in the claims at the end of this patent is referred to in this patent in a 
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maimer consistent with a single meaning, that is done for sake of clarity only so as to 
not confuse the reader, and it is not intended that such claim term by limited, by 
implication or otherwise, to that single meaning. Finally, it is not intended that the 
scope of any claim element be iaterpreted based on the application of 35 U.S.C. § 
5 112, sixth paragraph. 

Gaining System 

Fig. 1 illustrates one possible embodiment of a gaming system 10 in 
accordance with the invention. Referring to Fig. 1, the gaining system 10 may 
include a group or network 12 of gaming units 20a, 20b, 20c operatively coupled to a 

10 network computer 22 via a network data link or bus 24. Network 12 may also include 
a registration unit 26a operatively coupled to the network computer 22 and to the 
gaming units 20a, 20b, 20c via network the data link 24. Network 12 may be 
operatively coupled to a network 40 via a network link 42. The network 12 may 
comprise, for example, a area network (WAN), a local area network (LAN), a 

15 wireless LAN (e.g., the IEEE 802. llx standards), links according to the 
BLUETOOTH™ standard, cellular links, two-way paging links, etc. The network 40 
may comprise, for example, the Internet, a WAN, an intranet, an extranet, a LAN, a 
wireless LAN (e.g., the IEEE 802.1 Ix standards), links according to the 
BLUETOOTH™ standard, cellular liiJcs, two-way paging links, etc. 

20 The gaming system 10 may also include a website server 50 and one or more 

gaining servers 52 operatively coupled to the network 40 via the data links 54 and 56, 
respectively. The gaming system 10 additionally includes an authentication server 58 
operatively coupled to the network 40 via the data link 60. The gaming system 10 
may further include gaming units 20d and 20e operatively coupled to the network 40 

25 via the data links 64 and 66, and to a registration unit 26b via the data link 70. The 
.network 40 may include a plurality of network computers or server computers (not 
shown), e ach o f which may be o peratively i nterconnected. W here the network 4 0 
comprises the Internet, data communication may take place over any of the data hnks 
42, 54, 56, 60, 64, 66, and 70 via an Internet communication protocol. 

30 The network computer 22, the gaming units 20, the registration units 26, the 

gaming server 52, the website server 50, and the authentication server 58 may be 
located in a same physical location, or in different, remote locations, such as different 
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buildings, cities, or states. For example, network 12 may be located in a casino or 
hotel, and the website server may be located at a web hosting company. Continuing 
with this example, the gaming sei-ver 52 and the authentication server 58 may be 
located at a gaming company, and the gaming units 20d and 20e may be located in 
5 different households. Fiirther, the registration unit 26b maybe located at a notary 
public's office. 

Although Fig. 1 illustrates that the gaming system 10 comprises particular 
numbers of gaming units 20, registration units 26, gaming servers 52, etc., for sake of 
simplicity, it should be xmderstood that different numbers of these components could 
10 be used. For instance, although Fig. 1 illustrates five gaming units 20, the gaming 
system 10 may include many more gaming units 20, such as hundreds or thousands. 
As another example, although Fig. 1 illustrates one gaming- server 52, the gaming 
system 10 may include a plurality of gaming servers. 

Each of the registration units 26 may include, or be operatively coupled with, 
15 a device for obtaining biometric data fixim a person, where the biometric data may be 
used to uniquely identify that person. For instance, the registration units 26 may 
include a finger print scaiming device, an eye scanning device, a facial recognition 
system, a voice analyzer, etc. In some embodiments, the registration units 26 are 
located i n c ontrolled e nvironments s uch t hat i t can b e a ssured ( with s ome 1 evel o f 
20 certainty)thatthepersonsfromwhombiometricdataareobtainedare actuallythe 
persons they claim to be. For example, a registration unit 26 or 28 could be located in 
a casino and be operable only by an employee of the casino. 

Each of the gaining units 20 may also include, or be operatively coupled with, 
a device for obtaining biometric data from a person. This device should correspond tO' 
25 the biometric devices used by the registration units 26. For example, if the 
registration imits 26 include, or are operatively c oupled with, finger print scanning 
devices, at least some of the gaming units 20 should include, or be operatively 
coupled with, finger print scanning devices. 

Further, each of the gaming units 20 may also include, or be operatively 
30 coupled with, a position sensor for obtaining a geographic position of the gaming unit. 
For example, the gaming units 20 may include a wide area location system such as a 
global positioning system (GPS) device, a Loran-C device, etc. The gaming units 20 
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also may include a local area positioning system such as an in-building location 
system. 

The network computer 22 may be a server computer and may be used to 
accumulate and analyze data relating to the operation of the gaming units 20. For 
5 example, the network computer 22 may continuously receive data from each of the 
gaming units 20 indicative of the dollar amoimt and number of wagers being made on 
each of the gaming units 20, data indicative of how much each of the gaming units 20 
is paying out in winnings, data regarding the identity and gaming habits of players 
playing each of the gaming units 20, etc. 

10 Although network 12 is shown to include one network computer 22 and four 

gaming units 20, it should be understood that different numbers of computers and 
gaming units may be utilized. For example, the network 12 may include a plurality of 
network computers 22 aad tens or hundreds of gaming units 20, all of which may be 
interconnected via the data link 24. 

15 Each of ttie data links 24, 42, 54, 56, 60, 64, 66, and 70 may comprise a 

dedicated hardwired link, a wkeless Unk, intermediate computers (e.g., servers, 
gateways, network bridges, wireless access points, cellular/pager base stations, etc.), 
etc. 

It is to be understood that the gaming system 10 need not include all the 
20 components illustrated in Fig. 1 . Examples of gaming systems 10 that include subsets 
of the components illustrated in Fig. 1 are described below. 

Tn-Rnmn flaminp' 

In one scenario, the gaming system 10 may include the network 12 (e.g., the 
network computer 22, the gaming units 20a, 20b, and 20c, and the registration unit 

25 26a, coupled with the network data link 24). As an example, the gaming units 20a, 
20b, and 20c may be located in different hotel rooms of a casino, the registration unit 
26a located at the hotel's reception, and the network computer 22 located in a secure 
location of the hotel. In another scenario, the gaming system 10 may also include the 
authentication server 58 coupled to the network 12 via the network 40 and the data 

30 link 42. These particular gaming systems can be used for "m-room gaming" in which 
a user can play wagering games via a gaming unit in the privacy of his or her own 
hotel room. 
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Internet Gaming 

In yet another scenario, the gaming system 10 may include the website server 
50, the gaming server 52, the gaming units 20d and 20e, and the registration unit 26b, 
coupled together via tihie network 40. As an example, the gaming units 20d and 20e 

5 could be personid computers located in different residences, and ttxe registration unit 
26b may be located in a casino. Additionally, the website server 50 may be located at 
a company that operates a website, and the gaming server 52 may be located at a 
casino. These components may be operatively coupled together via the network 40, 
which includes the Internet. In another example, the gaming system may additionally 

1 0 include t he authentication s erver 5 8 o peratively coupled t o t he n etwork 4 0. T hese 
particular gaming system can be used for "internet gaming" in which a user can play 
wagering games via a personal computer in the privacy of his or her own residence. 

Overall Operation 

During operation, a user could utilize one of the registration units 26 to 

15 register with a gaming service. The gaming service could facilitate playing various 
wagering games such as poker, blackjack, slots, bingo, keno, etc., via the gaming 
units 20. Fig. 2 is a simplified flow diagram of one possible embodiment of a method 
of registering witii a gaming service. At block 78, a user may submit personal 
information such as name, date of birth, etc. At block 80, at least some of the 

20 personal information may be verified. For example, if the registration unit 26 is - • 
located in a casino, an employee of the casino could verify the personal information 
by examining a driver's license, identity card, passport, etc. of the user. 

At block 82, the user may submit biometric data via the registration unit 26. 
For example, if the registration unit 26 is coupled with a finger print scanning device, 

25 the finger print scanning device may scan the user's fingerprint and generate digital 
data representing the fingerprint. At block 84, the personal information submitted at 
block 78 and the biometric data submitted at block 82 are stored. This information 
may be stored, for example, in a smart card, a memory, a database, etc. In gaming 
systems that include an authentication server 58, the authentication server 58 may be 

30 configured to receive and store personal information and biometric data received firom 
the registration units 26. 
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Once registered with the gaming service, a user could "log on" via the gaming 
unit 20 and play a wagering game. Fig. 3 is a simplified flow diagram of one possible 
embodiment of a method of logging on to a gaming service operated on the gaming 
system 10. At block 86, the location of the gaming unit 20 to which a user is 
5 attempting to "log on" may be determined. For instance, if the gaming unit 20 
includes a position sensing device, the location of the gaming unit 20 can be 
determined by examining position data generated by the position sensing device. At 
block 87, it may be determined whether the location of the gaming unit 20 is in a 
location in which games to be played are permitted. For instance, wagering games are 

10 legal in only certain jurisdictions. Thus, if the gaming unit (for example, a lap top 
computer) is located in a jurisdiction in which wagering games are not legal, the user 
may not be permitted access to the games. As another example, it may be desired to 
permit a user to gamble with a mobile gaming unit 20 (e.g., a personal digital assistant 
with wireless cormectivity) only within a building or set of buildings (e.g., a casino 

15 and hotel). Thus, ifthe gaming unit is brought outside the' building (e.g., the parking 
lot), the user may not be permitted access to the games. Blocks 86 and 87 may be 
omitted if limiting access base on location is not desired. 

At block 88, a user may be prompted, by a gaming unit 20, to submit 
biometric data. For example, in embodiments in which the gaming unit 20 is coupled 
20 with a finger print scamiing device, the gaming unit 20 could display a screen or 
window that prompts the user to have their finger print scanned. At block 90, the user 
may submit biometric data using the gaming unit 20. In embodiments in which the 
gaming unit 20 is coupled with a finger print scaiming device, the user's finger print 
maybe scanned. 

25 Then, at block 92, the biometric data obtained at block 90 may be compared 

with biometric data, obtained previously (e.g., via a registration unit 26), of registered 
users of the gaming service. In embodiments in which the gaming unit 20 is coupled 
with a finger print scanning device, the finger print data obtained at block 90 may be 
compared with finger print data of registered users. If the biometric data does not 

30 match, the user may not be permitted to play a game. If the biometric data does 
match a registered user, it may be determined, at block 94, whether the user is 
permitted to play a game. For example, if the personal data, obtained previously (e.g., 
via a registration unit 26), indicates that the user is too young to play a wagering 
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game, the user may not be permitted to play. Similarly, if the user is on a "black list" 
of persons not permitted to play games of the gaming service, the user may not be 
permitted to play. At block 96, the user may be permitted to play a game via the 
gaming unit 20. Block 94 may be omitted if it is not desired to limit access in this 
5 way. For example, underage persons could be prevented from registering in the first 
place. 

Registration Units 

Each registration unit 26 may be disposed in a different location, such as a 
casino, a hotel, a notary public's office, etc. Typically, the registration units 26 are 

10 located in a controlled environment, such that there may be some level of assurance 
that data obtained via the registration unit 26 is accurate. As one example, a 
registration unit 26 may be located in a casino, and not operable by the general pubUc. 
Rather, a casino employee can operate the registration unit 26. If a person wishes to 
register with the gaming service, the casino employee can input personal information 

15 of the person using the registration unit 26 after verifying the information by, for 
example, examining a driver's license, identification card, passport, etc. Further, the 
casino employee can operate the registration unit 26 to obtain biometric data from the 
person. For example, if the registration unit includes a finger print scanning device, 
the casino enaployee can operate the registration unit 26 and instruct the person so as 

20 to obtain data representing the person's fingerprint. 

In other embodiments, a user may submit personal information without 
supervision. The information may be verified by, for example, requesting the user 
mail a copy of a driver's Ucense, passport, etc. In some embodiments, the personal 
information need not be verified. 

25 Each registration unit may be eitiier a smart terminal, such as a personal 

computer, a laptop computer, a personal digital assistant (PDA), etc., or a dumb 
terminal that does not include a controller. Fig. 4A is a block diagram of one possible 
embodiment of one of the registration units 26. Although one of the registration units 
26 is described below in connection with Fig. 4A, it should be understood that the 

30 structure of the registration units 26 may be different, and each of the registration 
units 26 may have a different design or structure than other registration units 26. 
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Fig. 4A is a simplified block diagram illustrating a number of components that 
may be incorporated in one embodiment of a registration unit. The registration unit 
lOOA may include a controller 101 that may comprise a- program memory 102, a 
microcontroller or microprocessor (MP) 104, a random-access memory (RAM) 106 
5 and an input/output (I/O) circuit 108, all of which may be intercoimected via an 
address/data bus 110. It should be appreciated that although only one microprocessor 
104 is shown, the controller 101 may include multiple microprocessors 104. 
Similarly, the memory of the controller 101 may include multiple RAMs 106 and 
multiple program memories 102. Although the I/O circuit 108 is shown as a single 
10 block, it should be appreciated that the J/0 circuit 108 may include a number of 
different types of 1/0 circuits. RAM(s) 104 and program memories 102 may be 
implemented as semiconductor memories, magnetically readable memories, and/or 
optically readable memories, for example. 

Program memory 102 may be a read-only memory (ROM), or a read/write or 
15 alterable memory, such as a hard disk. In the event a hard disk is used as a program 
memory, the address/data bus 110 shown schematically in Fig. 4A may comprise 
multiple address/data buses, which may be of different types, and there may be an I/Q 
circuit disposed between the address/data buses. The network data link 24, 70 may be - 
operatively coupled to the I/O circuit 108. 

20 The registration unit lOOA may include a display unit 1 12, which may be any 

type of display unit such as a cathode-ray tube (CRT), a flat panel display, etc. 
Additionally, the registration unit lOOA may include one or more input devices 114 
such as a keyboard, mouse, bar code scanner, smart card reader, a touch sensitive 
device associated with the display unit 112, etc. Further, the registration unit lOOA 

25 may include a fingerprint scamiing device 116 which may be any device capable of 
detecting the fingerprint of a person and generating digital data representing the 
fingerprint. The registration unit lOOA and the fingerprint scanning device 116 may 
be configured so that the fingerprint scanning device 116 may removable couple with 
the registration unit. Additionally, the fingerprint scanning device 116 may be 

30 integrated with the registration unit lOOA. In one specific embodiment, the 
fingerprint scanning device 116 may be integrated with a touch screen of the 
registration unit lOOA. Additionally, the registration unit lOOA may include a smart 
card reader/writer 1 17. 
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Components 112, 114, 116, and 117 may be operatively coupled to the I/O 
circuit 108, and can be so coupled by either a unidirectional or bidirectional, single- 
line or multiple-line data linlc, which may depend on the design of the component that 
is used. Additionally, components 112, 114, 116, and 117 may be connected to the 
5 I/O circuit 108 via a respective direct line or conductor, or different connection 
schemes could be used. For example, one or more of the components shown in Fig. 
4A may be connected to the I/O circuit 108 via a common bus or other data link that 
is shared by a number of components. Furthermore, some of the components may be 
directly connected to the microprocessor 104 without passing through the I/O circuit 
10 108. 

Fig. 4B is a block diagram of a second possible embodiment lOOB of a 
registration unit 26 (Fig. 1). Referring to Fig. 4B, the registration unit lOOB may be 
identical to the registration unit lOOA described above in connection with Fig. 4A, 
except that an eye scanning device US may be utilized instead of the fingerprint 
15 scanning device 116. The eye scanner 118 may be any type of device that is capable 
of detecting a portion of the eye of a person, such as the iris or retina of a person's 
eye, and generating digital data representing an image of the eye or digital data 
representing physical characteristics of the eye. 

Fig. 4C is a block diagram of a third possible embodiment lOOC of one of the 
20 registration unit 26 (Fig. 1). Referring to Fig. 4C, the registration unit lOOC may be 
identical to the registration unit lOOA described above in coimection witii Fig. 4A, 
except that a camera 120 may be utilized instead of the fingerprint scanner 116. The 
camera 120, which may be any type of camera or a combination of a camera and data- 
processing circuitry, may be used to generate a digital image of a portion of a person, 
25 such as a person's face. 

Fig. 4D is a block diagram of a fourth possible embodiment lOOD of one of 
the registration unit 26 (Fig. 1). Referring to Fig. 4D, the registration unit lOOD may 
be identical to tiie registration unit 100 A described above in connection with Fig. 4A, 
except that a voice analyzer 122 and a microphone 124 maybe utilized instead of the 
30 fingerprint scanner 116. The microphone 124 may be used to generate a voice signal 
in response to detecting sound correspondmg to one or more words spoken by a 
person. The voice signal could be provided to the voice analyzer 122, which could be 
any type of device or circuit, such as the combination of a sampling and analog-to- 
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digital converter circuit or a portion of a voice-recognition circuit, which may 
generate a d igital v oice signature o r d igital d ata r epresenting t he u nique f requency 
characteristics of a person's voice. In some embodiments, the voice signal may be 
provided to an analog-to-digital converter, and the controller 101 may generate the 
5 digital voice signature or digital data representing the unique frequency characteristics 
of the person's voice. 

Referring again to Fig. 1, it is to be understood that if the gaming system 10 
includes a plurality of the registration units 26, the registration units 26 may all be of 
■ the same type, or each registration unit 26 may be of a different type. For example, 
10 some registration units 26 may be of a type similar to those described with reference 
to FIGs. 4A-4D, while others may be of a different type. 

Gaming Units 

Each gaming unit 20 may be disposed in a different location, such as a hotel 
room, a restaurant, an airport, a person'shome, etc. E ach gaming unit 20 maybe 
15 either a smart terminal, such as casino gaming unit, a video gambling machine, a 
computer-based kiosk, a personal computer, a laptop computer, a PDA, etc., or a 
dumb terminal that does not include a controUa:. 

Fig. 5 is a perspective view of one possible embodiment of one or more of the 
gaming units 20. It should be understood that the design of one or more «f the 
20 gaming units 20 may be dijfferent than the design of other gaming units 20. Some of 
the gaming units 20 may be any type of casino gaming unit and may have various 
different structures and methods of operation. For purposes of setting forth exaniples, 
various designs of the gaming units 20 are described below, but it should be 
understood that numerous other designs may be utilized. 

25 Referring to Fig. 5, the casino gaming unit 20 may include a housing or 

cabinet 150 and one or more input devices, which may include a coin slot or acceptor 
152, a paper currency acceptor 154, a ticket reader/printer 156 and a card reader 
and/or writer (hereinafter "card reader/writer") 158, which may be used to input value 
to the gaming unit 20. A value input device may include any device that can accept 

30 value from a c ustomer. A s u sed h erein, t he t erm " value" m ay e ncompass g aming 
tokens, coins, paper cuirraicy, ticket vouchers, credit or debit cards, smart cards, and 
any other object representative of value. 
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If provided on the gaming unit 20, the ticket reader/printer 1 56 may be used to 
read and/or print or otherwise encode ticket vouchers 160. The ticket vouchers 160 
may be composed of paper or another printable or encodable material and may have 
one o r m ore o f t he following i nformational i tems p tinted ore needed t hereon: t he 
5 casino name, the type of ticket voucher, a validation number, a bar code wdth control 
and/or security data, the date and time of issuance of the ticket voucher, redemption 
instructions and restrictions, a description of an award, and any other information that 
may be necessary or desirable. Different types of ticket vouchers 160 could be used, 
such as bonus ticket vouchers, cash-redemption ticket vouchers, casino chip ticket 

10 vouchers, extra game play ticket vouchers, merchandise ticket vouchers, restaurant 
ticket vouchers, show ticket vouchers, etc. The ticket vouchers 160 could be printed 
with an optically readable material such as ink, or data on the ticket vouchers 160 
could be magnetically encoded. The ticket reader/printer 156 may be provided with 
the ability to both read and print ticket vouchers 160, or it may be provided with the 

15 ability to oiily read or only print or encode ticket vouchers 610. In the latter case, for 
example, some of the gaming units 20 may have ticket printers 156 that may be used 
to print ticket vouchers 160, which could then be used by. a player in other gaming 
units 20 that have ticket readers 156. 

If provided, the card reader/writer 158 may include any type of card 
20 reading/writing device, such as a magnetic card reader/writer or an optical card 
reader/writer, and may be used to read data from and/or write data to a card offered by 
a player, such as a credit card, a smart card, a player tracking card, etc. If provided 
. for player tracking purposes, the card reader/writer 158 may be used to read data 
from, and/or write data to, player tracking cards that are capable of storing data 
25 representing the identity of a player, the identity of a casino, the player's gaming 
habits, etc. 

The gaming unit 20 may include one or more audio speakers 162, a coin 
payout tray 164, an input control panel 166, and a color video display unit 170 for 
displaying images relating to the game or games provided by the gaming unit 20. The 
30 audio speakers 162 may generate audio representing sounds such as the noise of 
spinning slot machine reels, a dealer's voice, music, amiouncements or any other 
audio related to a casino game. The input control panel 166 may be provided with a 
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plurality of pushbuttons or touch-sensitive areas that may be pressed by a player to 
select games, make wagers, make gaming decisions, etc. 

Fig. 5 A illustrates one possible embodiment of the control panel 166, which 
may be used where the gaming miit 20 may be a slot machine having a plurality of 
5 mechanical or "virtual" reels. Referring to Fig. 5 A, the control panel 1 66 may include 
a "See Pays" button 172 that, when activated, causes the display unit 170 to generate 
one or more display screens showing the odds or payout information for the game or 
games provided by the gaming unit 20. As used herein, the term "bxitton" is intended 
to encompass any device fliat allows a player to make an inpiit, such as an input 
10 device that must be depressed to make an input selection or a display area that a 
player may simply touch. The control panel 166 may include a "Cash Out" button 
174 that may be activated when a player decides to tenninate play on the gaming unit 
20, in which case the gaming unit 20 may return value to the player, such as by 
iretuming a number of coins to the player via the payout tray 164. 

15 If the gaming unit 20 provides a slots game having a plurality of reels and a 

plurality of paylines which define winning combinations of reel symbols, the control 
panel 166 may be provided with a plurality of selection buttons 176, each of which 
allows the player to select a different number of paylines prior to spinning the reels. 
For example, five buttons 176 may be provided, each of which may allow a player to 

20 ' select one, three, five, seven or nine paylines. 

If the gaming unit 20 provides a slots game having a plurahty of reels, the 
control panel 166 may be provided with a plurality of selection buttons 178 each of 
which allows a player to specify a wager amoimt for each payhne selected. For 
example, if the smallest wager accepted by the gaming unit 20 is a quarter ($0.25), the 

25 gaming imit 20 may be provided with five selection buttons 178, each of which may 
allow a player to select one, two, three, four or five quarters to wager for each payline 
selected. In that case, if a player were to activate the "5" button 176 (meaning that 
five paylines were to be played on the next spm of the reels) and then activate the "3" 
button 178 (meaning that three coins per payline were to be wagered), the total wager 

30 would be $3.75 (assuming the minimum bet was $0.25). 

The control panel 166 may include a "Max Bet" button 180 to allow a player 
to make the maximum wager allowable jfor a game. In the above example, where up 
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to nine paylines were provided and up to five quarters could be wagered for each 
payline selected, the maximum wager would be 45 quarters, or $11.25. The control 
panel 166 may include a spin button 182 to allow the player to initiate spinning of the 
reels of a slots game after a wager has been made. 

5 In Fig. 5A, a rectangle is shown around the buttons 172, 174, 176, 178, 180, 

182. It should be understood that that rectangle simply designates, for ease of 
reference, an area in which the buttons 172, 174.176, 178, 180, 182 may be located. 
, Consequently, the term "control panel" should not be construed to imply that a panel 
or plate separate from the housing 150 of the gaming unit 20 is required, and the term 

1 0 "control panel" may encompass a plurality or grouping of player activatable buttons. 

Although one possible control panel 166 is described above, it should be 
understood that different buttons could be utilized in the control panel 166, and that 
the particular buttons used may depend on the game or games that could be played on 
the gaining unit 20. Although the control panel 166 is shown to be separate from the 
1 5 display unit 170, it should be understood that the control panel 1 66 could be generated 
by the display unit 170. In that case, each of the buttons of the control panel 166 
could be a colored area generated by the display unit 170, and some type of 
mechanism may be associated with the display unit 170 to detect when each, of the 
buttons was touched, such as a touch-sensitive screen. 

20 The gaming unit 20 may also include, or be operatively coupled with, a 

biometric device (not shown in Fig. 5) for submitting biometric data. The biometric 
device may be, for example, a fingerprint scanning device, an eye scanning device, a 
facial recognition device, a voice recognition device, etc. The biometric device may 
include a mechanism for' providing feedback to a user. For example, a fingerprint 

25 scanning device may include a light that goes on while a scan is taking place. As 
another example, a fingerprint scanning device may include a qjeaker that generates a 
"beep" when a scan is completed. In other embodiments, display unit 170 and/or 
audio speakers 162 maybe used to provide feedback to a user regarding the biometric 
device. For example, when a fingerprint scan is completed, a message may be 

30 displayed on display 170, or a sound generated by audio speakers 162, indicating to 
the user that the scan has been completed. 
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In some embodiments, the gaming unit 20 may include a slot, port, connector, 
etc., (not shown in Fig. 5) configured to accept a biometric device. In these 
embodiments, a biometric device can be removably coupled to the gaming unit 20 via 
the slot, port, connector, etc. For instance, a biometric device configured to 
5 removably couple with a gaming unit 20 can be given to, registered to, sold to, rented 
to, etc., a user. Then, when a user desires to play a game on a gaming unit 20, the 
user could "plug in" the biometric device to the gaming unit 20 and submit biometric 
data to gain access to games. 

In one embodiment, a smart card may include a biometric device (e.g., a 
10 fingerprint scanner) for obtaining biometric data &om a person, and the card 
reader/writer 158 could be configured to accept the smart card witii the biometric 
device. 

In other embodiments, the biometric device 116 maybe integrated with the 
gaming unit 20. For example, a fingerprint scanning device may be integrated with a 
15 touch screen, a keyboard, a button, a handle, etc., of the gaming unit 20. In one 
embodiment, a fingerprint scanning device may be integrated with a button, area of a 
touch screen, area of a control panel, handle, etc., corresponding to a "spin," "deal," 
"hit," "play," etc., selection on the gaming unit 20; 

In some ' embodiments, submission of biometric data may correspond to a 
20 . player's choice to play a game. For example, if a fingerprint scanner is integrated 
with a button, area of a touch screen, area of a control panel, a handle, etc. 
corresponding to a spin s election for a reel-type game, submission to a fingerprint 
scan may indicate the user's choice to spin. 

Further, t he gaming u nit 2 0 m ay i nclude, o r b e operatively c oupled w ith, a 
25 location device (not shown in Fig. 5) that generates data indicating its location. The 
location device could be, for example, a GPS device, a Loran-C device, etc. In some 
embodiments, the gaming unit 20 may include a slot, port, connector, etc., (not shown 
in Fig. 5) configured to accept a location device. In these embodiments, a location 
device can be removably coupled to the gaming unit 20 via the slot, port, connector, 
30 etc. For instance, a location device configured to removably couple with a gaming 
unit 20 can be given to, registered to, sold to, rented to, etc., a user. Then, when a 
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user desires to play a game on a gaming unit 20,' the user could "plug in" the location 
device to the gaming unit 20 to gain access to games. . 

Gaming Unit Electronics 

Fig. 6 is a block diagram of a number of components that may be incorporated 
5 in the gaming unit 20. Referring to Fig. 6, the gaming unit 20 may include a 
controller 200 that may comprise a program memory 202, a microcontroller or 
microprocessor (MP) 204, a random-access memory (RAM) 206 and an input/output 
(I/O) circuit 208, all of which may be interconnected via an address/data bus 210. It 
should be appreciated that although only one microprocessor 204 is shown, the 

10 controller 200 may include multiple microprocessors 204. Similarly, the memory of 
the controller 200 may include multiple RAMs 206 and multiple program memories 
202. Although the I/O circuit 208 is shown as a single block, it should be appreciated 
that the I/O circuit 208 may include a number of different types of 1/0 circuits. The 
RAM(s) 204 and program memories 202 may be implemented as semiconductor 

15 memories, magnetically readable memories, and/or optically readable memories, for 
example. 

Program memory 202 may be a read-only memory ("ROM), or a read/write or 
alterable memory, such as a hard disk. In the event a hard disk is used as a program 
memory, the address/data bus 210 shown schematically in Fig. 6 may comprise 
20 multiple address/data buses, which may be of different types, and there may be an I/O 
circuit disposed between the address/data buses. The network data link 24, 64. 66 
may be operatively coupled to the I/O circuit 208. 

Fig. 6 illustrates that the control panel 166, the coin acceptor 152, the bill 
acceptor 154, the card reader/writer 158 the ticket reader/printer 156, and the display 

25 device 170 may be operatively coupled to the I/O circuit 208, each of those 
components being so coupled by either a unidirectional or bidirectional," single-line or 
multiple-line data link, which may depend on the design of the component that is 
used. The speaker(s) 162 may be operatively coupled to a sound circuit 212, that may 
comprise a voice- and sound-synthesis circuit or that may comprise a driver circuit. 

30 The sound-generating circuit 212 may be coupled to the I/O circuit 208. Additionally, 
a biometric device 214 and a position sensing device 216 each may be operatively 
coupled to the I/O circuit 208, each of those components being so coupled by either a 
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unidirectional or bidirectional, single-line or multiple-line data link, which may 
depend on the design of the component that is used. 

As shown in Fig. 6, the components 152, 154, 156, 158, 166, 170, 212, 214, 
and 216 may be connected to the I/O circuit 208 via a respective direct line or 
5 conductor. Different connection schemes could be used. For example, one or more 
of the components shown in Fig. 6 may be connected to the I/O circuit 208 via a 
common bus or other data link feat may be shared by a number of components. 
Furthermore, some of the components may be directly connected to the 
microprocessor 204 without passing through the I/O circviit 208. 

1 0 Other Types of Gaming Units 

It is to be understood that the gaming units 20 may be of the same type or each 

may be of different types. Generally, the location at which the gaming unit 20 may be 
. used may be a factor in selecting the type of gaming unit. For example, a gaming unit 

20 of a type sunilar to that described with reference to Fig. 5 may be desirable for 
15 some locations (e.g., a casino, an airport, an off-track betting facility, etc.) but may 

not be desirable for others (e.g., a private residence, a hotel room, a restaurant, etc.). 

Some types may include many components, such as components 152, 154, 156, 158, 

162, 166, 170, 212, 214, and 216, while other types may iiiclude a lesser number of 

components. For instance, some gaming units 20 niay be designed to be free-standing 
20 and include many components, while others may be designed for a desk top or ■ 

counter top and include only a few components. In one specific example, a gaming 

unit 20 may be a personal computer. 

Some gaming units 20 may be of a type similar to the registration units 26 
described with reference to Figs. 4A-4D. Further, some gaming units 20 may be 
25 identical, or substantially identical, to the registration units 26. Moreover, some 
gaming units 20 may also serve as registration units 26. 

Authentication Server 
Fig. 7 is a simplified block diagram illustrating a number of components that 
may be incorporated in one embodiment of an authentication server. The 
30 authentication server 58 may include a controller 301 that may comprise a program 
memory 302, a microcontroller or microprocessor (MP) 304, a random-access 
memory (RAM) 306 and an input/output (I/O) circuit 308, all of which may be 
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interconnected via an address/data bus 310. It shoidd be appreciated that although 
only one microprocessor 304 is shown, the controller 301 may include multiple 
microprocessors 304. Similarly, the memory of the controller 301 may include 
multiple RAMs 306 and multiple program memories 302. Altliough the I/O circuit 
5 308 is shown as a single block, it should be appreciated that the I/O circuit 308 may 
include a number of different types of I/O circuits. RAM(s) 304 and program 
memories 302 may be implemented as semiconductor memories, magnetically 
readable memories, and/or optically readable memories, for example. 

Program memory 302 may be a read-only memory (ROM), or a read/write or 
10 alterable memory, such as a hard disk. Jn the event a hard disk is used as a program 
memory, the address/data bus 310 shown schematically in Fig. 7 may comprise 
multiple address/data buses, which may be of different types, and there may be an I/O 
circuit disposed between the address/data buses. The network data link 60 may be 
operatively coupled to the I/O circuit 308. Although only one network data link 60 is 
15 shown, it is to be understood the authentication server 58 may be coupled to multiple . 
network data links. 

The authentication server 58 may include a display unit 312, which may be 
any type of display unit such as a cathode-ray tube (CRT), a flat panel display, etc. 
Additionally, the authentication server 58 may include one or more input devices 314 
20 such as a keyboard, mouse, etc. Also, the authentication server 58 may include a 
server operating system. 

Components 312, 314, may be operatively coupled to the I/O circuit 308, and 
can be so coupled by either a unidirectional or bidirectional, single-line or multiple- 
line data link, which may depend on the design of the component that is used. 

25 Additionally, components 3 12, 3 14, maybe coimected t.o the I/O circuit 3 08 via a 
respective d irect 1 ine o r c onductor, o r d ifferent c onnection s chemes c ould b e u sed. 
For example, one or more of the components shown in Fig. 7 may be connected to the 
I/O circuit 308 via a common bus or other data link that may be shared by a number 
of components. Furthermore, some of the components may be directly connected to 

30 the microprocessor 304 without passing through the I/O circuit 308. 

Additionally, the authentication server 58 may be operatively coupled to a 
registration database (not shown) via a data link 316. Data link 316 may be 
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Qperatively coupled with the I/O circuit 308 via a dedicated link 316, or different 
connection schemes could be used. For example, the data link 316 maybe a common 
bus or other data link that shared by a number of components, and/or shared with data 
link 60. Furthermore, the data link 316 may be directly connected to the 
5 microprocessor 304 without passing tiirou^ the I/O circuit 308. 

Website Server 

Fig. 8 is a simplified block diagram illustrating a number of components that 
may be incorporated in one embodiment of an authentication server. The website 
server 50 may include a controller 351 that may comprise a program memory 352, a 

10 naicrocontroller or microprocessor (MP) 354, a random-access memory (RAM) 356 
and an input/output (I/O) circuit 358, all of which may be interconnected via an 
address/data bus 360. It should be appreciated that although only one microprocessor 
354 is shown, the controller 351 may include multiple microprocessors 354. 
Similarly, the memory of the controller 351 may include multiple RAMs 356 and 

15 multiple program memories 352. Although the I/O circuit 358 is shown as a single . 
block, it should be appreciated that the I/O circuit 358 may include a number of 
different types of VO circuits. RAM(s) 354 and program memories 352 naay be 
implemented as semiconductor memories, magnetically readable memories, and/or 
optically readable memories, for example. 

20 Program memory 352 may be a ROM, or a read/write or alterable memory, 

such as a hard disk. In tihe event a hard disk is used as a program memory, tiie 
address/data bus 360 shown schematically in Fig. 8 may comprise multiple 
address/data buses, which may be of different types, and there may be an I/O circuit 
disposed between the address/data buses. The network data link 56 is operatively 

25 coupled to the I/O circuit 358. Although only one network data link 56 is shown, it is 
to be understood the website server 50 may be coupled to multiple network data hnks. 

The website server 50 may include a display unit 362, which may be any type 
of display unit such as a CRT, a flat panel display, etc. A dditionally, the website 
server 50 may include one or more input devices 364 such as a keyboard, mouse, etc. 
30 Also, the website server 50 may include a server operating system. 

Components 362, 364, may be operatively coupled to the I/O circuit 358, and 
can be so coupled by either a unidirectional or bidirectional, single-line or multiple- 
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line data link, which may depend on the design of the component that is used. 
Additionally, c omponents 3 62, 3 64, m ay b e connected t o the I/O c ircuit 3 58 v ia a 
respective d irect 1 ine o r c onductor, o r d ifferent c onnection s chemes c ould b e u sed. 
For example, one or more of the components shown in Fig. 8 may be cormected to the 
5 I/O circuit 358 via a common bus or other data link that may be shared by a number 
of components. Furthermore, some of the components may be directly connected to 
the microprocessor 354 without passing through the 1/0 circuit 358. 

Gaining Servers 

Although one possible embodiment of one of the gaming server 52 is 
10 described below in connection with Fig. 9, it should be understood that, if multiple 
gaming servers 52 are employed, the structure of the gaming servers 52 could be 
different than that described and that each gaming server 52 could have a different 
structure. 

Fig. 9 is a simplified block diagram illustrating a number of components that 
15 ■ may be incorporated in one embodiment of a gaming server. The gaming server 52 
may include a controller 401 that may comprise a program memoiy 402, a 
microcontroller or microprocessor (MP) 404, a random-access memory (RAM) 406 
and an input/output (I/O) circuit 408, all of which may be interconnected via an 
address/data bus 410. It should be appreciated that althougih only one microprocessor 
20 404 is shown, ttie controller 401 may include multiple microprocessors 404. 
Similarly, the memory of the controller 401 may include multiple RAMs 406 and 
multiple program memories 402. Although the I/O circuit 408 is shown as a single 
block, it should be ^preciated that the I/O circuit 408 may include a number of 
different types of I/O circuits. RAM(s) 404 and program memories 402 may be 
25 implemented as semiconductor memories, magnetically readable memories, and/or 
optically readable memories, for example. 

Program memory 402 may be a read-only memory (ROM), or a read/write or 
alterable memory, such as a hard disk. In the event a hard disk is used as a program 
memory, the address/data bus 410 shown schematically in Fig. ,9 may comprise 
30 multiple address/data buses, which may be of different types, and there may be an VO 
circuit disposed between the address/data buses. The network data link 54 may be 
operatively coupled to the I/O circuit 408. Altiiough only one network data link 54 is 
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shown, it is to be understood that the gaming server 52 may be coupled to multiple 
network data links. 

The gaming server 52 may include a display unit 412, which may be any type 
of display unit such as a CRT, a flatpanel display, etc. A dditionally, the gaming 
5 server 52 may include one or more input devices 414 such as a keyboard, mouse, etc. 
Also, the gaming server 52 may include a server operating system. 

Components 412, 414, may be operatively coupled to the I/O circuit 408, and 
can be so coupled by either a unidirectional or bidirectional, single-line or multiple- 
line data link, which may depend on the design of the component that is used. 

10 Additionally, c omponents 4 12, 4 14, m ay b e connected to the I/O c ircnit 4 08 v ia a 
respective d irect 1 ine o r c onductor, o r d ifferent c onnection s chemes c ould b e u sed. 
For example, one or more of the componaits shown in Fig. 9 may be connected to the 
I/O circuit 408 via a common bus or other data link that is shared by a number of 
components. Furthennore, some of the components may be directly connected to the 

15 microprocessor 404 without passing through the I/O circuit 408. 

Network Computer 

Fig. 10 is a simplified block diagram illustrating a number of components that 
may be incorporated in one embodiment of a network computer. The network 
computer 22 may include a controller 451 that may comprise a program memory 452, 

20 a microcontroller or microprocessor (MP) 454, a random-access memory (RAM) 456 
and an input/output (I/O) circuit 458, all of which may be interconnected via an 
address/data bus 460. It should be appreciated that although only one microprocessor 
454 is shown, the controller 451 may include multiple microprocessors 454. 
Similarly, the memory of the controller' 451 may include multiple RAMs 456 and 

25 multiple program memories 452. Although the I/O circuit 458 is shown as a single 
block, it should be predated that tihie I/O circuit 458 may include a number of 
• different types of I/O circuits. RAM(s) 454 and program memories 452 may be 
implemented as semiconductor memories, magnetically readable memories, and/or 
optically readable memories, for example. 

30 Program memory 452 may be a ROM, or a read/write or alterable memory, 

such as a hard disk. In the event a hard disk is used as a program memory, the 
address/data bus 460 shown schematically in Fig. 10 may comprise multiple 
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address/data buses, which may be of different types, and there may be an I/O circuit 
disposed between the address/data buses. The network data link 24 may be 
operatively poupled to the I/O circuit 458. Although only one network data link 24 is 
shown, it is to be understood the network computer 22 may be coupled to multiple 
5 network data links. 

The network computer 22 may include a display unit 462, which may be any 
type of display unit such as a CRT, a flat panel display, etc. Additionally, the network 
computer 22 may include one or more input devices 464 such as a keyboard, mouse, 
etc. 

10 Components 462, 464, may be operatively coupled to the I/O circuit 458, and 

can be so coupled by either a unidirectional or bidirectional, single-line or multiple- 
line data link, which may depend on the design of the component that is used. 
Additionally, c omponents 4 62, 4 64, m ay b e connected t o t he I/O c ircuit 4 5 8 v ia a 
respective d irect 1 ine o r c onductor, o r d ifferent c oimection s chemes c ould b e u sed. 

15 For example, one or more of the components shown in Fig. 10 may be connected to 
the VO circuit 458 via a common bus or other data link that may be shared by a 
number of components. Furthermore, some of the components may be directly 
connected to the microprocessor 454 without passing through the I/O circuit 458. 

Registration Unit Operation 

20 One manner in which a registration unit 26 may operate is described below in 

connection with a number of flowcharts which represent a number of portions or 
routines of one or more computer progi-ams, which may be stored in one or more of 
the memories 102, 106 of the registration unit lOOA, lOOB, lOOC, or lOOD (Figs. 4A- 
4D). The computer program portions may be written m any high level language such 

25 as C, C+i C++ or tiie like or any low-level, assembly or machine language. By 
storing the computer program portions therein, various portions of the memories 102, 
106 are physically and/or structurally configured in accordance with computer 
program instructions. Additionally, it is to be understood that the computer program 
portions or routines may be implemented via display data (e.g., web pages, etc.) 

30 supplied to a registration unit 26, for example, by the network computer 22, the 
website server 50, or the authentication server 58 (Fig, 1). 
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Fig. 11 is a flowchart of one possible embodiment of an operation software 
routine 500 that may be performed by a registration unit 26. The flowchart will be 
described with reference to Figs. 1, 4A, and 12. At block 502, a user may be 
prompted to enter personal data. As one example, a registration display could be 
5 displayed on display unit 112. One example of a registration display 520 that could 
be displayed on display unit 112 is shown in Fig. 12. Registration display 520 could 
include a data entry box 522 for entry of the first name of a person wisliing to register, 
a data entry box 524 for entry of the last name of the person, a data entry box 526 for 
entry of the date of birth of the person, a data entry box 528 for entry of a credit card 

1 0 number of the person, and a data entry box 530 for entry of the credit card's expiration 
date. The registration display 520 could also include a submit button 532 which can 
be used by the user to submit the data. The registration display 520 could be 
generated by software running on the registration unit lOOA. Also, the registration 
display 520 could be received as display data (e.g., as a web page) from, for example, 

15 the network computer 22, the website server 50, or the authentication server 58 (Fig. 
1). 

Other personal data that may be obtained via. a registration display such as 
registration display 520 could include a desired login id, a password, a mailing 
address, an email address, a phone number, etc. 

20 In other embodiments, some or all of the information asked for in the example 

registration display 520 could be read from a smart card of the person provided any of 
this information is stored on the smart card. 

At block 504, it may be determined whether the personal data has been 
received. If no, the routine may branch back to block 502 to await, or prompt the 

25 user, for further personal data. At block 508, the user may be prompted to submit 
biometric data. For the registration units 26 that include a fingerprint scanner, such as 
registration unit lOOA of Fig. 4A, a display could be displayed on display unit 112 
that asks user to put a finger on the fingerprint scanner. Such a display could be 
generated by software running on the registration unit 100 A. Also, the registration 

30 display 520 could be received as display data (e.g., as a web page) firom, for example, 
the network computer 22 (Fig. 1), or the website server 50 (Fig. 1 ). 
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At block 510 it may be determined whether the biometric data has been 
received. For registration imits 26 that include a fingerprint scanner, such as 
registration unit lOOA of Fig. 4A, controller 101 could determine whether data 
representative of a fmgerprint had been received firom fingerprint scanner 116. If the 
5 biometric has not been received, the routine may branch back to wait for the data. 

The personal data and/or biometric data can be encrypted, or a digital 
signature can be applied to the data, at block 512. This would help to ensure that the 
data came from a reliable source, and thus help to increase the security of the overall 
system. This block may be omitted if desired. The biometric data could be 
10 encrypted, or a digital signature could be applied to it, by the controller 101, the 
biometric device (e.g., fingerprint scanning device 116 (Fig. 4A), eye scanning device 
118 (Fig. 4B), etc.), or some other device, and can be implemented via software, 
firmware, hardware, or some combination thereof. 

At block 514, the biometric data and the personal data are stored. The data 
15 can be stored, for example, in memory (e.g., a hard disk) of the registration unit 26. 
In embodiments that include a smart card reader/writer 1 17, the data can be stored on 
ai smart card. In embodiments that include a network computer 22, the data can be 
transmitted to the network computer 22 for storage. The data may be transmitted, for 
example, via the network data link 24. In embodiments that include an authentication 
20 server 58, the data can be transmitted to the authentication server 58 for storage. The 
diata may be transmitted, for example, via the network data links 24 or 70, the network 
40, and the network data link 60. It is to be understood that the data need not be 
stored in one location. For example, in embodiments that incKide a network computer 
22, the data could be stored at tiie registration imit 26 and transmitted to the network 
25 22 for storage. Also, the biometric data and some of the personal data could be stored 
at the registration unit 26, and some or all of the personal data could be transmitted to 
the network computer 22 for storage. 

It is to be understood that the operations represented by the blocks of Fig. 1 1 
need not be performed at one time, or by one registration unit 26. For example, a user 
30 could submit personal data (blocks 502" and 504) at a first time. Then, at a later time, 
the user could submit the biometric data (blocks 508 and 510). In this example, steps 
512 and 514 could be performed twice: once for the personal data and once for the 
biometric data. 
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As another example, a user could submit personal data (blocks 502 and 504) 
from a personal computer (registration unit) at the user's residence,. via a website 
served by the website server 50 or the authentication server 58 (Fig. 1). Then, the 
website could instruct the user to go to a specific location (e.g., a casino) to submit 
5 biometric data. At a later time, the tiser could visit the specijaed location to submit the 
biometric data. If at a casino, a casino employee could verify the identity of the 
person, verify the personal data previously submitted by the person, and then operate 
a registration unit 26 to obtain the person's biometric data (blocks 508 and 510) and 
transmit it to the authentication server 58 (block 514). 

10 Fig. 13 is a flowchart of one possible embodiment of an operation software 

routine 550 that may be performed by a registration unit lOOA (Fig. 4A) to obtain a 
fingerprint scaji of a user. The routine 550 may be part of a computer program, which 
may be stored in the program memory 102 (Fig. 4A) of any of the registration units 
26 (Fig. 1), that controls the operation of the registration units 26 to generate 

15 biometric data related to a person. The routine 550 may be used by the registration 
units lOOA (Fig. 4A) having, or configured to operatively couple with, fingerprmt 
scanning devices 116 described above in connection with Fig, 4A. Similar routines 
may be used with the registration units lOOB-lOOD (Figs. 4B-4D),. The routine 550 
may attempt to generate digital data that uniquely represents tlie physical 

20 characteristics of a person, such as a person's fingerprint, and thus uniquely identifies 
the person. 

At block 552, the controller 101 of the registration unit lOOA may cause the 
display unit 112 to display a visual message that prompts the user to place his or her 
finger on a scanner of fmgerprint scanning device 116, for example. At block 554, 
25 the fingerprint scanning device 116 may scan the person's fingerprint and generate 
digital data representing the person's fingerprint, as described above. At block 556, 
the digital data representing the person's fingerprint may be stored, for example, in 
the memory 1 06 of the registration unit 1 OOA. 

Blocks 5 52-556 m ay b e r epeated a n umber oft imes, i f d esired, tog enerate 
30 digital data representing a composite fmgerprint scan, which may be generated by 
averagmg each set of digital fingerprint data, for example. Perfotming multiple scans 
may increase the reliability and/or accuracy of the scan data. If multiple scans are not 
used, the operation represented by blocks 558 and 560 may be omitted. 
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If multiple scans are used to generate data representing a composite scan, at 
block 558 the controller 101 may determine whether all of the scans have been made. 
That determination may be made, for example, simply by determining whether a 
predetermined number of scans has been made, such as five scans. If all of the scans 
5 have not been made, the program may branch back to block 552 so that another scan 
may be performed. If all the scans have been made, the controller 101 may determine 
a composite scan based on all the scans made, such as by averaging the digital data 
for each scan. Such an average could be made, for example, by averaging the pixel 
intensity of each set of scan data on a pixel-by-pixel basis. 

10 Although the enrollment routine 550 has been described above in connebtion 

with the fmgerprint scanning device 116 of Fig. 4A, it should be understood that the 
same or a similar routine could be used to "train" the system to recognize other umque 
physical characteristics of a person, such as a person's eye, face or voice as described 
above. 

1 5 For example, if the routine 550 is used in coimection with the registration unit 

lOOA having the voice analyzer 122 and the microphone 124 (Fig. 4D), at block 554, 
instead of performing a scan of a person's fingeiprint, the person may speak into the 
microphone 124, and the voice analyzer 122 may generate a set of digital data 
represented the spoken word or words. That digital voice data may be treated and 

20 processed by tiie routine 550 in the same (or a similar) manner as the digital 
fingerprint data as described above. 

In other embodiments, a person may be prompted to scan multiple fingers, 
and/or to provide different types of biometric data. For example, a person may be 
prompted to sjibmit one or more fingerprint scans and a retinal scan. One of ordinary 
25 skill in the art will recognize many possible variations. 

Gaming Unit Operation 

One manner in wliich a gaming unit 20 may operate is described below in 
connection with a number of flowcharts which represent a numbei* of portions or 
routines of one or more computer programs, which may be stored in one or more of 
30 tiie memories 202, 206 of the gaming unit 20. The computer program portions may 
be written in any high level language such as C, C+, C++ or the Uke or any low-level, 
assembly or machine language. By storing the computer program portions therein, 
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various portions of the memories 202, 206 are physically and/or structurally 
configured in accordance with computer program instructions. Additionally, it is to 
be understood that the computer program portions or routines may be implemented 
via web pages supplied to a gaming unit 20 by, for example, the network computer 
5 22, the website server 50, the gaming server 52, or the authentication server 58 (Fig. 

1). 

Main Routine 

Fig. 14 is a flowchart of one possible embodiment of an operation software 
routine 600 that may be performed by a gaming unit 20, and will be described with 

10 reference to Fig. 1. At block 602, data may be obtained including personal data of the 
user. This data may include, for example, a name, a login id, etc. The data may be 
obtained, for example, by prompting the user to submit the data via a keyboard or 
touch screen. In embodiments of gaming units 20 that include a smart card 
reader/writer, the data may be obtained fiom a smart card inserted by the user. The 

15 dataobtainedatbl6ck602maybeused,forexample,tolocate,ina database, tlie 
biometric data that the user submitted while registCTing for the gaming service. Block 
602 is optional and may be omitted if desired. 

At block 604, data may be obtained from the user including biometric data. 
Examples of techniques for obtaining biometric data, personal data, and location data 

20 will be described below. At block 606, data related to the location of the gaming unit 
20 may be obtained. Block 606 is optional and may be omitted if desired. 

In embodiments tiiat employ positioning data, at block 608, it may be 
determined whether the position data obtained at block 606 indicates that the gaming 
unit 20 is' in a location in which playing games via tiie gaming system 10 is permitted, 

25 Ifno, the routine may branch back to block 6 02. If the location is permitted, the 
routine may proceed to block 610. In some embodiments, block 608 may be 
implemented at the gaming unit 20, In oflier embodiments, block 608 may be 
implemented in conjunction with the authentication server 58, For example, the 
gaming unit 20 may transmit the position data to the authentication sei-ver 58, Then, 

30 the authentication server 58 may determine whether the location of the gaming unit is 
a pemiitted location. Next, tiie authentication server 58 may transmit a message to the 
gaming unit 20 that indicates whetiier the position is permitted. Similarly, block 608 
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may be implemented in conjunction with the network computer 22, the gaming server 
52, the website server 50, etc. 

At block 610, the biometric data obtained at block 604 may be compared with 
biometric data previously obtained during registration to determine if it matches. In 

5 some embodiments, block 610 may be implemented at the gaming unit 20. For 
example, the gaming unit 20 could be operatively coupled with a smart card 
reader/writer. In this example, the user could insert into the smart card reader/writer a 
smart card that included a registered user's biometric data. Then, the gaming unit 20 
could compare the biometric data obtained at block 604 with the biometric data of the 

1 0 registered user stored on the smart card. 

Additionally, block 610 could be implemented in conjunction with the 
authentication server 58. For example, the gaming unit 20 may transmit the biometric 
data obtained at block 604 to the authentication server 58. Then, the authentication 
server 58 can determine whether the received biometric data matches biometric data 
15 . of a registered user. Next, the authentication server 58 may transmit a message to the 
■ gaming unit 20 that indicates whether the user is.permitted to play a game. Similarly, 
block 610 may be implemented in conjunction with the network computer 22, the 
gaming server 52, the website server 50, etc. 

If at block 610 it may be determined that the biometric data obtained at block 
20 604 matches that of a registered user, control may pass to block 612. Otherwise, 
control may pass to block 602. At block 612, the user may be provided access to play 
a game on the gaming system 10. 

At block 606, the authentication server 58 may or may not grant the user 
access to the gamiTig service in response to the data transmitted at block 604. If the 
25 authentication server 58 does not grant access, the routine may return to block 602 to 
await new data. 

Obtain Biometric Data 

Fig. 15 is a flowchart of one possible embodiment of an operation software 
routine 620 that may be performed by a gaming unit 20. The routine 620 can be used 
30 to obtain data jfrom a user in order to authenticate the user, and will be described with 
reference to Figs. 1 and 6. At block 622, a user may be prompted to enter personal 
data. As one example, fixe user could be prompted, via display unit 170, to enter 
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personal data (e.g., a logon id, a last name, etc.) that can be used to identify a record 
of a registered user. Such a display could be generated by software running on the 
gaining unit 20. Also, the registration display 520 could be received as display data 
(e.g., as a web page) from, for example, the network computer 22, the website server 
5 50, the authentication server 58 (Fig. 1), etc. 

At block 624, it may be determined whether the personal data has been 
received. If no, the routine may branch back to block 622 to await, or prompt the 
user, for further personal data. At block 626, the user may be prompted to submit 
biometric data. For gaming units that include a fingerprint scanner, such as the 
10 gaming unit 20 of Fig. 6, a display could be displayed on display unit 170 that asks 
user to put a fmger on the fingerprint scanner. Such a display could be generated by 
software running on the gaming unit 20. Also, the display could be received as 
display data (e.g., as a web page) from, for example, the network computer 22, the 
website server 50, the authentication server 58 (Fig. 1), etc. 

15 : At block 628 it may be determined whether the biometric data has been 

received. For gaming units that include a fingerprint scanner, such as the gaming unit 
20 of Fig. 6, controller 200 could determine whether data representative of a 
fingerprint had been received- &om the fingerprint scanner. If the biometric data, has 
not been received, the routine may branch back to wait for the data. 

20 The personal data and/or biometric data can be encrypted, or a digital 

signature can be apphed to the data, at block 630. This would help to ensure that the 
data came from a reliable source, and thus help to increase the security of the overall 
system. This block may be omitted if desired. The biometric data could be 
encrypted, or a digital signature could be appUed to it, by the controller 200, the 

25 biometric device 214, or some other device, and can be implemented via software, 
firmware, hardware, or some combination thereof. 

It is to be understood that, in some embodiments, personal data obtained at 
block 622 may not be needed for authentication. For example, authentication can be 
accomplished using only biometric data. Thus, blocks 622 and 624 can be omitted, 
30 and at block 612, only biometric data may be transmitted to the authentication server 
58. Also, as will be described below, a user may be required to authenticate liim or 
herself several times while playing a game. In these examples, flie personal data 
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obtained at blocks 622 and 624 need only be obtained once. Thus, in operation, 
blocks 622 and 624 may be performed once during the playing of a game, and omitted 
in subsequent authentications during the game. 

Obtain Locatioa Data 

5 Fig. 16 is a flowchart of one possible embodiment of an operation software 

routine 650 that may be performed by a gaming unit 20. The routine 650 can be used 
to obtain information regarding the location of the gaming unit 20, and will be 
described with reference to Figs. 1 and 6. It is to be understood that, in some 
embodiments, the routine 650, or a similar routine, need not be implemented. For 

10 instance, in some embodiments, authentication of tlie location of the gaming unit 20 
may not be needed. In other embodiments, location of the gaming imit 20 can be 
obtained by means that do not employ a location system operatively coupled with the 
gaming unit 20, an example of which will be described below. 

At block 652, flie gaming urut 20 obtains location data from the location 
15 sensing device 216. At block 654, the location data may be encrypted, or a digital 
signature may be applied to it. niis would help to ensure that the location data came 
■from a reliable source, and thus help to increase the security of the overall system. 
This blbck may be omitted if desired. Block 654 can be implemented, for example, 
by the controller 200, the location sensing device 216, or some other device, and can 
20 be implemented via .software, fmnware, hardware, or some combination thereof 

Auflientication Server Operation 
One manner in which the autiientication server 58 may operate is describe 
below in connection with flowcharts that represent a number of portions or routines of 
one or more computer programs, which may be stored in one or more of the memories 
25 302, 306 of the authentication server controller 301. The computer program portions 
may be written in any high level language such as C, C+, C++ or the like or any low- 
■ level, assembly or machine language. By storing the computer program portions 
therein, various portions of the memories 302, 306 are physically and/or structurally 
configured in accordance with computer program instructions. 

30 Rejaister User 

The manner of operation described below will be described with reference to 
Figs. 1 and 7. Fig. 17 is a flowchart of one possible embodiment of an operation 
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software routine 700 that may be performed by the authentication server 58. The 
routine 700 can be used to register a user who desires to play games via a gaming 
system. 

At block 702, the authentication server 58 receives the personal data and 
5 biometric data transmitted by a registration unit 26. It is to be understood that the 
personal data and biometric data need not be received at the same time, or ftom only 
one registration unit 26. Rather, as described previously, the authentication server 58 
can receive the data at multiple points in time, and can receive the data from multiple 
registration units 26. 

10 In embodiments in which the personal data and/or biometric data has been 

encrypted, and/or a digital, signature applied to it, the authentication server 58, at 
block 704, can decrypt the data and/or examine the digital signature to help determine 
if the data was received from a reliable source or sources. Block 704 can be 
implemented, for example, by the controller 301 or some other device, and can be 

1 5 implemented via software, firmware, hardware, or some combination thereof. 

If at block 704, it may be determined that the received data is not authentic, 
the authentication server 58 may, at block 706, transmit a failure message to the- 
registration unit or units 26 from -v^ch the data was received. The failure message 
may indicate that the authentication server 58 was unable to register the user, and may 

20 also indicate that it could not authenticate the data. 

If, at block 704, it may be determined that the personal data and/or biometric 
data is authentic, then the flow may proceed to block 708. In other embodiments, 
blocks 704 and 706 can be omitted. For example, blocks 704 and 706 can be omitted 
if tihie personal data and biometric data are not encrypted, or a digital signature is not 

25 applied to the data, prior to its receipt by the authqatication server 58. 

At block 708, the received personal data and biometric data are stored in the 
registration database. The registration database can be any type of suitable database 
such as a commercially available database from Oracle, Sybase, Microsoft, IBM, etc. 
It is to be understood that the personal data and biometric data need not be received 
30 and stored at the same time. For example, the personal data may be received at one 
time and the biometric data may be received at a later time. In this example, the 
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personal data can be stored first, and the biometric data can be stored later, after it is 
received. 

Check Location 

The manner of operation described below will be described with reference to 
5 Figs. 1 and 7. Fig. 18 is a flowchart of one possible embodiment of an operation 
software routine 750 that may be performed by the authentication server 58. The 
routine 7 50 c an b e u sed t o d etermine w hether t he 1 ocation o f t he g aming u nit i s a 
location at which playing games via the gaming system is pei-mitted. 

At block 752, the authentication server 58 receives data indicative of the 
10 location of a gaming unit. The location data can be, for example, an internet protocol 
(IP) address, location data &om a positioning device coupled with the gaming unit, 
etc. 

In embodiments in which location data has been encrypted, and/or a digital 
signature applied to it, the authentication server 58, at block 754, can decrypt the data 
15 and/or examine the digital signature to help determine if the data was received fi-om a 
rehable soiu-ce or soiu-ces. Block 754 can be implemented, for example, by the 
controller 301 or some other device, and can be implemented via software, firmware, 
hardware, or some combination thereof. 

if at block 754, it may be determined that the received data is not authentic, 
20 the authentication server 58 may, at block 756, transmit a denial message to the 
gaming unit. The denial message may indicate, for example, that the authentication 
■ server 58 determined that the location data was not authentic. 

If, at block 754, it may be determined that the location data is authentic, then 
control may pass to block 758. In other embodiments, block 754 can be omitted, if, 
25 for example, the location data are not encrypted, or a digital signature is not applied to 
the data, prior to its receipt by the authentication Server 58. 

At b lock 758,itmaybed etermined w heftier t he 1 ocation d ata i ndicates the 
gaming unit is at a permitted location. In embodiments in which the location data 
includes an IP address of the gaming unit, the gaming unit TP address, for example, 
30 can be compared to a list of permitted IP addresses. Also, the IP address, for 
example, can be mapped to a geographic area, and the geographic area compared with 
permitted geographic areas. 
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In embodiments in which the location data includes geographic position 
infonnation, the geographic position information, for example, can be compared with 
permitted geographic areas. In embodiments in which the location data includes in- 
building position information, the in-building position information can be compared 
5 with permitted in-building areas. For instance, the in-building position infonnation 
may indicate that the gaming unit is outside the building, whereas playing games may 
only be permitted within tiie building. 

If it is determined fhat the location data indicates the gaming unit is not in a 
permitted location, control may pass to block 756. At block 756, the authentication 
10 server 58 denies the user access to the gaming system. In some embodiments, the 
authentication server 58 may transmit a denial message to the gaming unit. The 
denial message may indicate that the authentication server 58 determined that the 
location data indicated the location of the gaming unit was not permitted. 

If at block 758 it is determined that the gaming unit is in a permitted location, 
1 5 control may pass to block 760. At block 760, the authentication server 58 grants the 
user further access to the gaming system 10. For example, in some embodiments, the 
authentication server 58 may transmit a message to the gaming unit indicating that" the 
gaming unit is at a permitted location. In other embodiments, the authentication 
server 58 may pass control to the website server 50 or the gaming server 52, 
20 indicating that the gaming unit is at a permitted location. 

Check Biometric Data 

The manner of operation described below will be described with reference to 
Figs. 1 and 7. Fig. 1 9 is a flowchart of one possible embodiment of a software routine 
770 that may be performed by the authentication server 58. The routine 770 can be 
25 used to determine whether the biometric data submitted by the user matches biometric 
data submitted during registratioa 

At block 774, the authentication server 58 receives biometric data. In 
embodiments in which biometric data has been encrypted, and/or a digital signature 
apphed to it, the authentication server 58, at block 778, can decrypt the data and/or 
30 examine the digital signature to help determine if the data was received from a 
reliable source or sources. Block 778 can be implemented, for example, by the 
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controller 301 or some other device, and can be implemented via software, firmware, 
hardware, or some combination thereof. 

If at block 778, it may be determined that tiie received biometric data is not 
authentic, the authentication server 58 may, at block 782, transmit a denial message to 
5 the gaming unit 20. The denial message may indicate that the authentication server 
58 determined that the location data was not authentic and/or that the location data 
indicated the location of the gaming unit 20 was not permitted. 

If, at block 778, it is detennined that tlie biometric data is authentic, then 
control may pass to block 786. In other embodiments, block 778 can be omitted, if, 
10 for example, the biometric data are not encrypted^ or a digital signature is not applied 
to the data, prior to its receipt by the authentication server 58. 

At block 786, it may be determined whether the biometric data matches 
biometric data previously submitted during registration. For example, the received 
biometric data may be compared with biometric data stored, for example, in a 

15 memory, database, etc., to determine if it matches any of the stored data. Also, if 
personal data associated with the received biometric data is available, this personal 
data may be used to retrieve stored biometric data from the memory, database, etc., 
that corresponds to the personal data. Then, the biometric data received at block 774 
can be compared with the biometric data retrieved from the memory, database, etc., 

20 that corresponds to the personal data. In another embodiment, the biometric data 
received at block 774 may be compared with biometric data stored on a smart card. 
This may include receiving the biometric data from the smart card via, for example, a 
gaming unit 20, and authenticating the smart card biometric data. If the smart card 
biometric data is authentic, the biometric data received.at block 774 may be compared 

25 with the smart card biometric data. 

If it is determined tliat the biometric data received at block 774 does not match 
biometric data previously obtained during regisfration, confrol may pass to block 782. 
At block 782, the authentication server 58 denies the user access to the gaming 
system. In some embodiments, the authentication server 5 8 may transmit a denial 
30 message to tlie gaming unit 20. The denial message may indicate, for example, that 
the authentication server 58 determined that the biometric data did not match 
biometric data of any registered users. 
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If at block 786 it is detennined that the biometric data received at block 774 
does match biometric data obtained during registration, control may pass to block 
790. At block 790, the authentication server 58 grants the user access to the gaming 
system IQ. In some embodiments, the authentication server 58 may transmit a 
5 message lo the gaming unit 20 indicating, for example, that the user's biometric data 
matches that of a registered user. In other embodiments, the authentication server 58 
may pass control to the website server 50 or the gaming server 52 indicating that, for 
example, that the user's biometric data matches that of a registered user. 

Website Server Operation 

10 Fig. 20 is a flowchart of one possible embodiment of an operation software 

routine 800 that may be performed by the website server 50. Referring to Fig. 20, at 
block 822 the website server 50 may determine whether a player has indicated a 
desire to stop playing a particular game that the player has been playing via one of the 
gaming servers 52. During play of a particular game, the gaming server 52 which 

1 5 provides the gaming software for that game controls the operation of the game. When 
the player indicates a desire to stop playing fliat game, the gaming sei-ver 52 may 
transfer operational control back to the website server 50, in which case the routuie 
may branch to block 824 at which a game selection display may be generated ofi tlie 
display unit 170 (Fig. 6) of the gaming unit 20 being used by the player, 

20 Atblock826,theroutinemaydeterminewhethera logonrequesthasbeen 

received from a player, via one of the gaming units 20, indicating a desire to initiate a 
• gaming session. The logon request could be, for example, the entry by the player of 
the Internet address of the website associated with the website server 50. If a logon 
. request is received, the routine may cause a logon display to be generated on tlie 

25 display unit 44 of the player who transmitted the logon request. To generate the logon 
display (block 828), the website server 50 may cause display data representing a 
logon display image to be transmitted to the gaming unit 20. Various image data, 
including logon image data, may be stored in one of the memories 352, 356 of the 
website server 50. 

30 • One example of a logon display 130 that could be generated on the player's 
display unit 44 is shown in Fig. 21. Referring to Fig. 21, the logon display 900 may 
includea data entrybox902forentryofthefirstnameoftheplayer. Thelogon 



wo 2004/095384 PCTAIS2004/007844 

40 

display 900 may also include a button 916 that a user may select to submit the data 
entered in the data entry box 902 of logon display 900. 

Other information could be additionally or alternatively obtained from the user 
such as a last name, a logon name, a password, a street address, a city, a state, a zip 
5 code, a credit card number, an expiration date of the credit card, etc. 

In some embodiments, some or all of this information may be obtained from a 
smart card of the player. In these embodiments, a logon display may additionally or 
alternatively prompt the player to insert his or her smart card into a smart card reader. 

Referring back to Fig. 20, if the website server 50 has received logon data 
10 from the p layer as d etermined at b lock 8 46, that d ata m ay b e stored in one o f the 
memoriess 352, 356 of the website server 50 at block 848. If the website server 50 has 
received all of the required logon data as determined at block 849, the routine may 
branch to block 824. If not, the routine may branch back to block 846 to await fiirther 
logon data from the player. 

15 At block 824, the routine may cause a game selection display to be generated 

on the display unit 170 of the gaming unit 20. To generate the game selection display, 
the website server 50 may cause display data representing a game selection display 
image to be transmitted to the gaming unit 20. The display data may be stored in one 
of memories 352, 356 of the website server 50. Block 824 may be performed in 

20 response t o a p layer i nitially 1 ogging o nto t he w ebsite (i.e. after t he c ompletion o f • 
block 849) or in response to a player's desire to end a game that is being provided 
under the control of one of the gaming servers 52 as described above (i.e. after the 
completion of block 822). 

One example of a game selection display 920 that could be generated on the 
25 player's display umt 170 is shown in Fig. 22. Refening to Fig. 22, tihie game selection 
display 920 may include a plurality of player-activatable icons, or game images, each 
of which represents a respective game that the player may play via tiie website 
associated with the website server 50. The icons may include, for example, an icon 
922 associated with a draw poker game, an icon 924 associated with a bonus poker 
30 game, an icon 926 associated with a triple play poker game, an icon 928 associated 
with a 10-play poker game, an icon 930 associated with a 50-play poker game, an 
icon 932 associated with a fust slots game, an icon 934 associated witli a second slots 
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game, an icon 936 associated with a blackjack game, an icon 938 associated with a 
bingo game, and an icon 940 associated with a keno game. Where the gaming unit 20 
includes a mo\ise, the icons may be player- activatable via the mouse. Alternatively, 
each of the game icons may have a unique letter associated therewith and a game 
5 couldbeselectedby inputting one ofthe unique letters via a keyboard. 

The games that are available to play via the website serviced by the website 
server 50 may be provided by the gaming servers 52 in various ways. For example, if 
twenty games were available via the website and if the website server 50 were 
operatively coupled to four gaming servers 52, each of those four gaming servers 52 
1 0 could be programmed to facilitate play of exactly five ofthe games. 

As another example, if the ten games represented by the ten icons shown in 
Fig. 22 were available for play and if four gaming servers 52 were connected to the 
website server 50, a first ofthe gaming servers 52 could be programmed with gaming 
software that facilitates play of each ofthe poker games rq)resented by the icons 922, 

15 924, 926, 928, 930, a second of tibie gaming servars 52 could be programmed with 
gaming software that fecilitates play ofthe two slots games rqpresented by the icons 
932, 934, a third gaming server 52 could be programmed with gaming software that 
facilitates play of the blackjack game rqpresented by the icon 936, and the fourfli 
gaming server 52 could be programmed with gaming software that facilitates play of 

20 the bingo and keno games represented by the icons 938, 940, Each g?me may be 
available for play via only one ofthe gaming servers 52. In other words, only one of 
the four gaming servers 52 could contain gaming software that fecilitates play ofthe 
triple play poker game represented by the icon 926, in which case that particular 
gaming server 52 would have to be utilized if a player desired to play the triple play 

25 poker game. 

Alternatively, each ofthe gaming servers 52 may provide a plurality of games 
that are available only firom a respective gaming provider. La that case, each ofthe 
gaming servers 52 may be programmed with gaming software that facihtates one or 
more poker games (and/or other games), but each of the poker games may be 
30 different, such as by having different visual displays, different wagering options, 
different gaming options, etc. 
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Each of the games available for play via the website may have one gaming 
server 52 on which gaming software that facilitates play of that game is stored. One 
of the memories 352, 356 of the website server 50 could store data that identifies the 
particular gaming server 52 that provides gaming software that implements each of 
5 the games available via the website. One example of such data is set forth below. 



Game Gaming Server 

Draw Poker #1 

Bonus Poker #1 

Triple Play Poker #2 

10 10-Play Poker #2 

50-Play Poker #2 

Slots A #3 

Slots B #3 

Blackjack #4 

15 Bingo #5 

Keno #6 



In some embodiments, one gaming server 52 may implement multiple tyi)es of 

game.s. 

Referring to Fig. 20, at block 874 if a player selected one of the games 
20 available via the website as described above, the routine may branch to block 876. At 
block 876, the routine may obtain location datai related to the gaming unit 20. For 
• instance, the website server 50 may prompt the gaming unit 20 to obtain location data 
and transmit the location data to the website server 50. The gaming unit 20 may 
utilize a routine such as routine 650 (Fig. 16) to obtain location data. Also, the 
25 website server 50 may obtain location data as the IP address of the gaming unit 20. 

At block 878, the routine may determine whether the location data obtained at 
block 876 indicates that the gaming unit 20 is at a permitted location. For instance, 
the website server 50 may transmit the location data obtained at block 876 to the 
authentication server 58, and request that the authentication server 58 determine 
30 whether the gaming unit 20 is at a permitted location. The authentication sender 58 
may utilize a routine such as routine 750 (Fig. 18) to determine whether the gaming 
unit 20 is at a permitted location. la embodiments that do not include an 
authentication servo: 58, the determmation of whether the gaming unit 20 is at a 
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permitted location may be carried with another computing system, such as the website 
server 50, the network computer 22, etc. 

In another embodiment, at blocks 876 and 878, operational control may pass 
from tiie website server 50 to the authentication server 58, or to whatever computing 
5 system that implements blocks 876 and 878. Then, operational control may pass back 
to the website server 50 at block 880. 

If it determined that the gaming unit 20 is at a permitted location, the routine 
may branch to block 882, at which the routine may obtain biometric data of the user 
to authenticate the user. For instance, the website server 50 may prompt the gaming 

10 unit 20 to obtain biometric data from the user and transmit the biometric data to the 
website server 50. The gaming unit 20 may utilize a routine such as routine 620 (Fig. 
15) to obtain biometric data. 

At block 884, the routine may determine whether the biometric data obtained 
at block 882 matches biometric data obtained previously." For instance, the website 

15 server 50 may transmit the biometric data obtained at block 882 to the authentication 
sCTver 58, and request that the autlientication server 58 determine whether that 
biometric data matches biometric data of a registered user. The authentication server 
58 may utilize a routine such as routing 770 (Fig. 19). In embodiments that do not 
include an authentication server 58, the determination of whether the biometric data 

20 matches biometric data of a registered user may be implemented with another 
computing device, such as the website server 50, the network computer 22, the 
•gaming unit 20 etc. For instance, the gaming unit 20 may compare the biometric data 
■ obtained from the player and compare it to biometric data stored on a smart card. 

Iq another embodiment, at blocks 882 and 884, operational control may pass 
25 ■ from the website server 50 to the authentication server 58, or to whatever computing 
system that implements blocks 882 and 884. Then, operational control may pass back 
to the website server 50 at block 886 

If the biometric data does match that of a registered user, and, optionally, tlie 
user identified by the biometric data is permitted to play, control may pass to block 
30 888. At block 888, operational control may pass to the gaming server 52 that 
provides gaming software to p lay that game. F or example, if the above t able was 
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used and if the player selected Triple Play Poker, the routine would transfer 
operational control to tiie gaming server #2. 

If the biometric data does not match that of a registered user permitted to play, 
or, optionally, the user identified by the biometric data is not permitted to play, 
5 control may pass to block 890. Similarly, if at block 870 it is determined that the 
gaming unit 20 is not at a permitted location, control may pass to block 890. At block 
890, a display may be generated which indicates to the user that he or she has been 
refused access to play the game. The display may optionally indicate why access was 
denied. 

10 If the player elected to end play at tlie website, such as by activating the "Sign 

Off' icon 942 shown in Fig. 22, the routine may branch to block 894 at which point a 
gaming session summary may be displayed on the display unit 170 of the gaming unit 
20. The gaming session summary may provide the player with summary data, such as 
how much money was won and what ganaes were played. The player could then print 

15 out tiie summary display shown on the display unit 170 to save a physical record of 
the gaming session. At block 896, the routine may terminate the Internet link between 
the website and the gaming unit 20. 

In some embodiments, blocks 876, 878, 880 and/or blocks 882, 884, 886, and 
block 890 may be omitted if desired. For example, location data and/or biometric 
20 data could be checked during game play. 

Gaming Server Operation 

As described above, each game available via the website may be played via 
one of the gaming servers 52 operatively coupled to the website server 50. Examples 
of the draw poker, slots A, blackjack, bingo and keno games represented by the game 
25 icons 152, 162, 166, 168, 170, respectively, shown in Fig. 22 are described below. In 
view of the above description, it should be understood that each of the following 
game routines may be performed by a different one of the gaming servers 52, or that 
one of the gaming servers 52 may perform more than one of titie game routines. 

One of tiie game routines described below may begin execution upon the 
30 transfer of operational control &om the website server 50 to one of the gaming servers 
52 as described above in comiection with block 888 of Fig. 20. Upon the completion 
of one of the game routines (i.e. when a player desired to stop playing a particular 
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game), the website server 50 would make that determination at block 822 of Fig. 20 
as described above and would begin operation at block 824 as described above. 

Draw Poker 

Fig. 23 is an exemplary display 950 that may be caused to be displayed on the 
5 display unit 170 of one of the ganung units 20 (by a gaming server 52 sending display 
data to the gaming unit 20) during performance of a draw poker routine that may be 
performed by one of the gaming servers 52. 

Referring to Fig. 23, the display 950 may include video images 951 of a 
plurality of playing cards representing the player's hand, such as five cards. To allow 
10 ■ the player to control the play of the poker ganie, a plurality of player-selectable 
buttons may be displayed. The buttons may include a "Hold" button 952 disposed 
directly below each of the playing card images 951', a "Cash Out" button 954, a "See 
. Pays" button 955, a "Bet One Credit" button 956, a ''Bet Max Credits" button 957, and 
a "Deal/Draw" button 958. The display 950 may also include an area 959 in v/hich 
15 the munber of remaining credits or value may be displayed. The buttons may be 
activated with the use of a mouse as ddscribed above. 

Upon activation of each of the buttons, a corresponding data message may be 
• transmitted from the gaming unit 20 to tlie gaming server 52. The data message may 
have a source address that identifies the gaming unit 20 sending the message, a. 
20 destination address that identifies the gaming server 52 to which the message is to be 
sent, and a data field that contains data corresponding to the button, such as wager 
data, game instruction data (e.g. whether to "deal," "hold," etc.), etc. 

In some embodiments one or more of the buttons 952, 954, 955, 956, 957, and 
958 may be integrated with a biometric device. For example, the "Deal/Draw" button 

25 may be integrated with a fingerprint scanner. In this example, the "Deal/Draw" 
button may be activated by providing placing a finger on the fingerprint scanner and 
submitting one or more fingerprint scans. The fingerprint seamier may be integrated, 
for example, with a touch screen, keyboard, control panel, lever, etc., such that tlie 
area on which a finger should be placed for scanning corresponds to a "Deal/Draw" 

30 selection. 

In other embodiments, the playar may be prompted to submit biometric data if 
he or she desires to make a particular selection, such as "Deal/Draw" selection. In 
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. Still other embodiments, when, for example, the "Deal/Draw" button is integrated witli 
the biometric device, the gaming unit 20 may determine that the player has made a 
"Deal/Draw" selection (e.g., by detecting a button press, touch screen press, etc.) and 
may also retrieve biometric data via the biometric device such that the two appear to 
5 occur simultaneously, or nearly simultaneously, to the player. 

Thus, submitting biometric data may be a mechanism for providing a game 
play selection (e.g., a "Deal/Draw" selection). Or, biometric data may be submitted in 
conjunction with making the game play selection. When such a selection is made, a 
corresponding data message may be transmitted firom flie gaming unit 20 to the 

10 gaming server 52. The data message may have a source address that identifies the 
gaming unit 20 sending the message, a destination address that identifies the gaming 
server 52 to which the message is to be sent, and a data field that contains biometric 
data, etc. The message may also include data corresponding to the selection to which 
the biometric data submission corresponds (e.g. whether to "deal," etc.) If the 

15 corresponding selection can be determined by the context of the game, this data need 
not be provided (but may be provided). . 

In other embodiments, location information may be determined in conjunction 
with the game play selection. In these embodiments, the data message transmitted 
&om the gaming unit 20 to the gaming server 52 may include location information. 

20 Fig. 24 is a flowchart of a poker routine 962. Referring to Fig. 24, at block 

964, if the player has requested payout information, such as by activating the "See 
Pays" button 955, at block 966 the routine may cause one or more pay tables to be 
displayed on the display unit 170 of the gaming unit 20 (by transmitting to the gaming 
unit 20 display data representing the pay tables). 

25 At block 968, flie player may make a bet by, for example, selecting the "Bet 

One Credit" button 956 (Fig. 23). This may be detected by.the gaming server 52, for 
example, by receiving a "Bet One Credit" message &om the gaming unit 20. If a "Bet 
One Credit" message is received, control may pass to block 976. At block 976, bet 
data corresponding to the b et made by the player may b e stored in a memory ( for 

30 example, the memory of the gaming server controller 401). 

At block 978, the routine may determine whether the player has activated the 
"Bet Max Credits" button 957, For example, the gaming server 52 may receive a "Bet 
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Max Credits" data message from the gaming unit 20. If yes, then control may pass to 
block. At block 980, bet data corresponding to the bet made by the player may be 
stored in a memory (for example, the memory of the gaming server controller 401). 

At block 982, the routine may determine if the player desires a new hand to be 
5 dealt, (for example, by receiving a "Deal/Draw" data message from the gaming unit 
20 after a wager was made). If yes, then control may pass to block 970. At block 
970, biometric data may be obtained from the player and checked to see whether it 
matches that of a registered user. For instance, tlie gaming server 52 may prompt the 
gaming unit 20 to obtain biometric data from ttie user and transmit the biometric data 
10 to the gaming server 52. The gaming unit 20 may utilize a routine such as routine 620 
(Fig. 15) to obtain biometric data. Additionally, the gaming server 52 may transmit 
• the obtained biometric data to the authentication server 58, and request that the 
authentication server 58 determine whether that biometric data matches biometric data 
of a re^stered user. The authentication server 58 may utilize a routine such as routine 
15 770 (Fig. 19). In embodiments that do not include an authentication server 58, the- 
determination of whether the biometric data matches biometric data of a registered 
user may be implemented with another computing device, such as the gaming ser\'er 
52, the network computer 22, the gaming unit 20.. etc. For instance, the gaming luiit 
. 20 may compare the biometric data obtained from the player and compare il to 
20 biometric data stored on a smart card. 

In another embodiment, at block 970, operational control may pass from the 
gaming server 52 to the authentication server 58, or to whatever computing system 
that implements block 970a. Then, operational control may pass back to tiie gaming 
server 52 at block 972 or block 984 (if access is granted). 

25 If at block 972 it is determined that access has not been granted, then the 

routine may end. If at block 972 it is determined that access has been granted, control 
may pass to block 984. 

As discussed previously, submission of biometric data may be integrated with 
the determination of whether the player desires a new hand to be dealt. For example, 
30 the player may submit biometric data in order to request, or when requesting, a new 
hand to be dealt. Thus, blocks 982, 970, and 972 may be integrated, their order 
rearranged, etc. 
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At block 984, a video poker hand may be "dealt" by causing the display unit 
. 1 70 to generate the playing card images 95 1 (by transmitting one or more messages to 
the gaming unit 20 with suitable display data). After the hand is dealt, at block 986 
the routine may determine if the player selected a "Hold" button 952. For example, 
5 the g aming s erver 5 2 m ay d etermine w hether a "Hold" d ata m essage w as r eceived 
from the gaming unit 20. If yes, data regarding which of the playing card images 95 1 
are to be "held" may be stored in a memory (for example, the memory of the gaming 
server controller 401) at block 388. 

If the user selects the "Deal/Draw" button 958 (for example, if the gaining 
10 server 52 receives a "Deal/Draw" data message from the gaming unit 20) as 
determined at block 990, each of the playing card images 95 1 that was not "held" may 

• be caused to disappear from the video display 950 and to be replaced by a new, 

• randomly selected, playing card image 95 1 at block 992. 

In some embodiments, the user may be required to submit biometric data in 
15 conjunction with block 990 in a manner similar that described above with respect to 
blocks 982, 970, and 972. For example, if a fingerprint scanner is integrated with the 
"Deal/Draw" selection "button," submission of bioinetric data maybe interpreted as a 
"Draw" request. 

At block 994, the routine may determine whether the poker hand represented 
20 by the playing card images 951 currently displayed is a winner. That determination 
may be made by comparing data representing the currently displayed poker hand with 
data representing all possible winning hands, which may be stored in a memory (for 
example, the memory of the gaming sei-ver controller 401). If there is a winning 
hand, a payout value corresponding to the winning hand may be determined at block 
25 996. At block 998, the player's cumulative value or number of credits may be updated 
by subtracting the bet made by the player and adding, if the hand was a winner, the 
payout value determined at block 996. The cumulative value or number of credits 
may also be displayed in the display area 959 (Fig. 23). 

If desired, one or more similar paurs of blocks 970 and 972 may be added in 
30 other portions of the routine as well. For example, after blocks 968 and/or 978, or 
integrated therewith, biometric data could be accessed and authenticated before 
passing control to block 976 or block 980, respectively. 
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Blackiack 

Fig. 25 is an exemplary display 1000 that may be caused to be displayed on 
tihie display unit 170 of one of the gaming units 20 (by a gaming server 52 sending 
display data to tiie gaming unit 20) during performance of a blackjack routine. 

5 Referring to Fig. 25, the display 1000 may include video images 1002 of a pair of 
playing cards representing a dealer's hand, with one of tihie cards shown face up and 
the other card being shown face down, and video images 1004 of a pair of playing 
cards representing a player's hand, with- both the cards shown face up. The "dealer" 
may be the gaming server 52. 

10 To' allow the player to control the play of the blackjack game, a plurality of 

•player-selectable buttons may be displayed. The buttons may include a "Cash Out" 
button 1006, a "See Pays" button 1008, a "Stay" button 1010. a "Hit" button 1012, a 
"Bet One Credit" button 1014, and a "Bet Max Credits" button 1016. The display 
1000 may also include an area 1018 in which the number of remaining credits or 

15 value is displayed. The buttons may be activated with the use of a mouse as described 
. above. 

Upon activation of each of the buttons, a corresponding data message may be 
transmitted ftom the gaming vmit 20 to the gaming server 52. The data message may 
have a source address that identifies the gaming unit 20 sending the message, a 
20 destination address that identifies the gaming server 5^ to which the message is to be 
sent, and a data field tiiat contains data corresponding to the button, such as wager 
data, game instruction data (e.g. whetiier to "hit" or "stay"), etc. 

Similar to the buttons described with reference to Fig. 23, in some 

• embodiments one ormore of thebuttons 1 006, 1 008. 1 010. 1 012. 1 014, and 1 016 
• 25 may be integrated with a biometric device. For example, the "Hit" button niay be 

•integrated with a biometric device. For instance, the "Hit" button may be integrated 

• with a biometric device in a similar manner as described with respect to the 
"Deal/Draw" button of Fig. 23. Or, the player may make a "Hit" selection by 
submitting biometric data via a biometric device. Thus, as described above, 

30 submitting biometric data may be a mechanism for providing a game play selection 
(e.g., a "Hit" s election). O r, b iometric d ata m ay be s ubmitted i n c onjunction w ith 
making the game play selection. 
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Fig. 26 is a flowchart of the blackjack routine 1020. Referring to Fig. 26, the 
blackjack routine 1020 may begin at block 1022 where it may determine whether a 
bet has been made by the player (e.g. by determining if a "Bet One Credit" data 
message or a "Bet Max Credits" data message has been received by the gaming server 
5 52 from the gaming unit 20). 

If a bet has been made, control may pass to blocdc 1028. At block 1028, bet 
data c orresponding t o t he b et m ade b y t he p layer m ay b e s tored i n a m emory ( for 
example, the memory of the gaming server controller 401). At block 1030, a dealer's 
hand and a player's hand may be "dealt" by making the playing card images 1002, 
10 1004 appear on the display unit 170 of the gaming imit 20. 

At block 1032, the player may select to be "hit," in which case control may 
pass to block 1024. At block 1024a, biometric data may be obtained from the player 
and c hecked t o s ee whether i t m atches that o f a registered u ser. For i nstance, the 
gaming server 52 may prompt the gaming unit 20 to obtain biometric data from the 

15 user and transmit the biometric data to the gaming server 52. The gaming unit 20 
may utilize a routine such as routine 620 (Fig. 15) to obtain biometric data. 
Additionally, the gaming server 52 may transmit the obtained biometric data tp the 
authentication server 58, and request that the aiithentication sender 58 detennine 
whether that biometric data matches biometric data of a registered user. The 

20 authentication server 58 may utilize a routine such as routine 770 (Fig. 19). In 
embodiments that do not include an authentication server 58, the determination of 
whether the biometric data matches biometric data of a registered user may be 
implemented with another computing device, such as the gaming server 52, the 
network computer 22, the gaming unit 20 etc. For instance, the gaming unit 20 may 

25 compare the biometric data obtained from the player and compare it to biometric data 
stored on a smart card. 

In another embodiment, at block 1024, operational control may pass from the 
gaming server 52 to the authentication server 58, or to whatever computing system 
that implements block 1024. Then, operational control may pass back to the gaming 

30 server 52 at block 1026 or at block 1034 (if access is granted). 

If the biometric data does match tiiat of a registered user, and, optionally, the 
user identified by the biometric data is permitted to play, control may pass to block 
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1034. At block 1034, another card will be dealt to the player's hand by making 
another playing card image 1004 appear in the display 1000. If the player is hit, block 
1036 may determine if the player has "bust," or exceeded 21. If the player has not 
bust, control may pass to block 1032. 

5 If at block 1026 it is determined that access has not been granted, the routine 

may end. Prior to ending, a display may be generated which indicates to the player 
that he or she has been refused access to play the game. The display may optionally 
mdicate why access was denied. Additionally, instead of ending, the routine may 
branch back to block 1022. 

10 As discussed previously, submission of biometric data may be integrated with 

the determination of whether the player desii-es a "Hit." For example, the player may 
submit biometric data in order to request, or when requesting, a "Hit." Thus, blocks 
1032, 1024, and 1026 maybe integrated, their order rearranged, etc. 

If the player decides not to hit, at block 1038 flie routine may determine 
15 whether tiie dealer should be hit. Whether the dealer hits may be determined in 
" accordance with predetermined rules, such as the dealer always hit if the dealer's hand 
totals 15 or less. If the dealer hits, at block' 1040 the dealer's hand may be' dealt 
ano&er card by making another playing ckrd imajge 1002 appear in the display 1000. 
At block 1042 the routine may determine whether the dealer has bust. If the dealer 
20 has not bust, blocks 1038 and 1040 may be performed again to allow Ihe dealer to be 
hit again. 

If the dealer does not hit, at block 1044 the outcome of the blackjack game and 
a corresponding payout may be determined based on, for example, whether the player 
or the dealer has the higher hand fliat does not exceed 21 . If the player has a winning 

25 hand, a payout value corresponding to the winning hand may be -determined at block 
1046. At block 1048, the player's cumulative value or number of credits may be 
updated by subtracting the bet made by the player and adding, if the player won, the 
payout value determined at block 1046. The cumulative value or number of credits 
' may also be displayed in the display area 1018 (Fig. 25). 

30 If desired, one or more of the pair of blocks 1024 and 1026 may be added in 

other portions of the routine as well. 
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Slots A 

Fig. 27 is an exemplary display 1050 that may be caused to be displayed on 
the display unit 170 of one of the gaming units 20 (by a gaming server 52 sending 
display data to tiie gaming unit 20) during performance of a slots routine. Referring 
5 to Fig. 27, the display 1050 may include video images 1052 of a plurality of slot 
machine reels, each of the reels having a plurality of reel symbols 1054 associated 
therewith. Although the display 1050 shows five reel images 1052, each of which 
may have three reel symbols 1054 that are visible at a time, other reel configurations 
could be utilized. 

10 To allow the player to control the play of tlie slots game, a plurality of player- 

selectable buttons may be displayed. The buttons may include a "Cash Out" button 
1056, a "See Pays" button 1058, aplurahty of payline-selection buttons 1060 each of 
which allows the player to select a different number of paylines prior to "spinning" 
the reels, a plurality of bet-selection buttons 1062 each of which allows a player to 

15 specify a wager amount for each payline selected, a "Spin" button 1064, and a "Max 
Bet" button 1066 to allow a player to make the maximum wager allowable. 

Upon activation of a button, a corresponding.data message may be transmitted 
from the gaming uiiit 20 to the gaming server 52, The data message, may have a , 
source address that identifies the gaming unit 20 sending the message, a destination 

20 address that identifies ttie gaming server 52 to which the message is to be sent, and a 
data field that contains data corresponding to the button, such as waga: data, game 
instruction data (e.g. spin), etc. 

Similar to the buttons described with reference to Fig. 23, in some 
embodiments one or more o f the buttons 1 056, 1 058, 1 060, 1 062, 1 064, and 1 066 

25 may be integrated with a biometric device. For .example, the "Spin" button may be 
integrated with a biometric device. For instance, the "Spin" button may be integrated 
with a biometric device in a similar manner as described with respect to the 
"Deal/Draw" button of Fig. 23. Or, the playei* may make a "Spin" selection by 
submitting biometric data via a biometric device. Thus, as described above, 

30 submitting biometric data may be a mechanism for providing a game play selection 
(e.g., a "Spin" selection). Or, biometric data may be submitted in conjunction with 
making the game play selection. 
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Fig. 28 is a flowchart of a slots routine 1068. Referring to Fig. 28, at block 
1070, it may be determined whether the player has requested payout information (e.g., 
detecting receipt by the gaming server 52 of a "See Pays" data message). If yes, at 
block 1072 the routine may cause one or more, pay tables to be displayed on tlie 
5 display unit 170. At block 1074, it may be determined whether the player selected a 
number of paylines (e.g., by selecting one of the payline buttons 1060). For example, 
the routine may determine if a data message is received by the gaming server 52 as a 
result of the player pressing one of the payline-selection buttons 460. If yes, at block 
1076 data corresponding to the number of paylines selected by the player may be 
10 stored in a memory (e.g., the memory 406 of the gaming server controller 401). At 
block 1078, it may be determined if the player has selected one of the bet-selection 
buttons 1062. 

If yes, control may pass to block 1084. At block 1084, data corresponding to 
the amount bet per payline may be stored in a memory (for example, the memory of 
15 the gaming server controller 401). 

Atblockl086,itmay bedeterminedwhethertheplayerselectedthe "Max • 
Bet" button 1066. For example, the routine may determine if a "Max Bet", data 
message has been received by the gaming server 52. If yes, control may pass to block 
1088. A t b lock 1 088, b et d ata (which m ay include b oth p ayline d ata and b et-per- 
20 payline data) corresponding to the maximum allowable bet may be stored in a 
memory (for example, the memory of the gaming server controller 401). 

At block 1090, it is determined whether the user selected the "Spin" button 
1064. For example, the routine may determine whether a "Spin" data message has 
been received from the gaming unit 20. If yes, control may pass to block 1080. At 

25 block 1080, biometric data may be obtained from the player and checked to see 
whether it matches that of a registered user. For instance, the gaming server 52 may 
prompt the gaming unit 20 to obtain biometric data fi-om the user and transmit tlie 
biometric data to the gaming server 52. The gaming unit 20 may utilize a routine 
such as routine 620 (Fig. 15) to obtain biometric data. Additionally, the gaming 

30 server 52 may transmit tlie obtained biometric data to the authentication server 58, 
and request that the authentication server 58 deteraiine whether that biometric data 
matches biometric data of a registered user. The authentication server 58 may utilize 
a routine such as routine 770 (Fig. 19). In embodiments that do not include an 
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authentication server 58, the determination of whether the biometric data matches 
biometric data of a registered user may be implemented with another computing 
device, such as the gaming server 52, the network computer 22, the gaming unit 20 
etc. For instance, tlie gaming unit 20 may compare the biometric data obtained from 
5 the player and compare it to biometric data stored on a smart card. 

In another embodiment, at block 1080, operational control may pass from the 

gaming server 52 to the authentication server 58, or to whatever computing system 

that implements block 1080. Then, operational control may pass back to the gaming 

server 52 at block 1082 or at block 1092 (if access is granted). 
10 If atblock 1082itisdeterminedthataccesshasnotbeengranted,thenthe 

routine may end. If at block 1082 it is determined that access has been granted, 

control may pass to block 1092. 

As discussed previously, submission of biometric data may be integrated with 

the determination of whether the player desires to "Spin." For example, the player 
15 may submit biometric data in order to request, or when requesting, to "Spin." Thus, 

blocks 1090, 1080, and 1082 may be integrated, their order rearranged, etc. 

At block 1092, the routine may cause the slot machine reel images 1052 to 
begin "spinning" so as to simulate the appearance of a plurality of spinning 
mechanical slot machine reels. At block 1094, the routine may determine the 

20 positions at w hich t he s lot m achine r eel i mages w iU s top, o r the p articular symbol 
images 1054 that will be displayed when the reel images 1052 stop spinning. At 
' block 1096, the routine may stop the reel images 1052 from spinning by displaying 
stationary reel images 1052 and images of three symbols 1054 for each stopped reel 
image 1052. The virtual reels may be stopped from left to right, from the perspective 

25 of the player, or in any other manner or sequence. 

The routine may provide for the possibility of a bonus game or round if certain 
conditions are met, such as the display in the stopped reel images 1052 of a particular 
symbol 1054. If there is such a bonus condition as determined at block 1098, the 
routine may proceed to block 1100 where a bonus round may be played. The bonus 

30 round may be a different game than slots, and many otlier types of bonus games could 
be provided. If the player wuas the bonus round, or receives additional credits or 
points in the bonus round, a bonus value may be determined at block 1 102. A payout 
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value corresponding to outcome of the slots game and/or the bonus round may be 
determined at block 1 104. At block 1 108, the player's cumulative value or number of 
credits may be updated by subtracting the bet made by the player and adding, if the 
slot g ame and/or b onus r ound w as a w inner, t he p ayout v alue d etennined at b lock 
5 1104. 

If desired, one or more of the pair of blocks 1080 and 1082 may be added in 
other portions of the routine. 

Keno 

Fig. 29 is an exemplary display 1120 that may be caused to be displayed on 
10 the display unit 170 of one of the gaming units 20 (by a gaming server 52 sending 
display data to the gaming unit 20) during performance of a keno routine. Referring 
to Fig. 29, the display 1 120 may include a video image 1 122 of a plurality of numbers 
that were selected by the player prior to the start of a keno game and a video image 
1124 of a plurality of numbers randomly selected during the keno game. The 
1 5 randomly selected numbers may be displayed in a gjid pattern . 

To allow the player to control the play of the keno game, a pluiality of player- 
selectable buttons may be displayed. The buttons may include a "Cash Out" button 
1126, a "See Pays" button 1128, a. "Bet One Credit" button 1130, a "Bet Max Cre-dits" 
button 1132, a "Select Ticket" button 1134, a "Select Number" button 1136, and a 
20 "Play" button 1138. The display 1120 may also include an area 1140 in which the 
number of remaining credits or value is displayed. 

Upon activation a button, a corresponding data message may be transmitted 
fiom the gaming unit 20 to the gaming server 52. The data message may have a 
source address that identifies the gaming imit 20 sending the message, a destination 
25 address that identifies the gaming server 52 to which the message is to be sent, and a 
data field that contains data corresponding to the. button, such as wager data, game 
iiistruction data, etc. • 

Similar to the buttons described with reference to Fig. 23, in some 
embodiments one ormore of thebuttons 1 126, 1 128, 1 132, 1 134, 1 136, and 1 138 
30 may be integrated with a biometric device. For example, the "Play" button may be 
integrated with a biometric device. For instance, the "Play" button may be integrated 
with a biometric device in a similar manner as described with respect to the 
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"Deal/Draw" button of Fig. 23. Or, the player may make a "Play" selection by 
submitting biometric data via a biometric device. Thus, as described above, 
submitting biometric data may be a mechanism for providing a game play selection 
(e.g., a "Play" selection). Or, biometric data may be submitted in conjunction with 
S making the game play selection. 

Fig. 30 is a flowchart of the keno routine 1150. The keno routine 1150 maybe 
utilized in cormection with a single gaming unit 20 where a single player is playing a 
keno game, or the keno routine 1150 may be utilized in connection with multiple 
gaming units 20 where multiple players are playing a single keno game. 

1 0 Referring t o F ig. 3 0, a t b lock 11 52. t he r outine may d etermine w hether the 

"See Pays" button 1128 was selected. For example, the routine may determine 
whether a "See Pays" data message has been received from the gaming unit 20. If 
yes, at block 154 the routine may cause one or more pay tables to be displayed on the 
display unit 170. At block 1 156, it maybe determined whether tiie player has chosen • 

15 to bet. For example, the routine may determine whether bet data has been received 
from the gaming unit 20, such as by receiving a "Bet One Credit" data message or a . 
"Bet Max Credits" data message. If yes, the routine may proceed to block 1 162. 

At block 1162, bet data corresponding .to the befmade by the player may 1?e,; 
stored in a memory (for example, the memory of the gaming server controller 401). 

20 After the player has made a wager, at block 1 1 64 the player may select a keno • 

ticket, and at block 1166 the ticket may be displayed on the display 1120. At block 
1 168, the player may select one or more game numbers, which may be within a range 
set by the casino. After being selected, the player's game numbers may be stored in a 
memory (e.g., the memory of the gaming server controller 401) at block 1170 and 

25 . may be included in the image 1 122 on the display 1 120 at block 1 172. After a certain 
amount of time, the keno game may be closed to additional players (where a number 
of players are playing a single keno game using multiple gaming imits 20). 

At block 1174, it may be determined whether play of the keno game is to 
begin. If yes, control may pass to block 1158. At block 11 58, biometric data may be 
30 obtained from the player and checked to see whether it matches that of a registered 
user. For instance, the gaming server 52 may prompt the gaming unit 20 to obtain 
biometiic data from tiie user and transmit the biometric data to the gaming server 52. 



wo 2004/095384 PCT/US2004/007844 

57 

The gaming unit 20 may utilize a routine such as routine 620 (Fig. 15) to obtain 
biometric data. Additionally, the gaming server 52 may transmit the obtained 
biometric data to the authentication server 58, and request that the authentication 
server 58 determine v/hether that biometric data matches biometric data of a 
5 registered user. The authentication server 58 may utilize a routine such as routine 770 
(Fig. 19). In embodiments that do not include an authentication server 58,' the 
determination of whether tiie biometric data matches biometric data of a registered 
user may be implemented with another computing device, such as the gaming server 
52, the network computer 22, the gaming unit 20 etc. For instance, the gaming unit 
10 20 may compare the biometric data obtained from the player and compare it to 
biometric data stored on a smart card. 

In another embodiment, at block 1158, operational control may pass from the 
gaming server 52 to the authentication server 58, or to whatever computing system 
that implements block 1158. Then, operational control may pass back to the gaming 
1 5 server 52 at block 1 1 60a. 

If the biometric data does match that of a registered user, and, optionally, the 
user identified by the biometric data is permitted to play, control may pass to block 
1 176. If the biometric data does not match that of a registered usei- permitted to play, 
then the routine may end. Prior to ending, a display may be generated which indicates 
20 to tibie player that he or she has been refused access to play the game. The display 
■ "may optionally indicate why access was denied. Additionally, instead of ending, the 
routine may branch back to block 1 152. 

As discussed previously, submission of biometric data may be integrated with 
the determination of whether the player desires to "Play." For example, the player 
25 may submit biometric data in order to request, or when requesting, to "Play." Thus, 
blocks 1 174, 1 158, and 1 160 may be integrated, their order rearranged, etc. 

At block 1176 a game number within a range set by the casino may be 
randomly selected (for example, by the gaming server controller 401). At block 1 178, 
the randomly selected game number may be displayed on the display unit 170 and the 
30 display units 170 of other gaming units 20 (if any) which are involved in the same 
keno game. At block 1180, a count which keeps track of how many game numbers 
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have been selected may be incremented at block 1180. For example, the gaming 
server controller 401 may increment the count. 

At block 1182, the routine may determine whether a maxunum number of 
game numbers within the range have been randomly selected. If not, another game 
5 number may be randomly selected at block 1 176. If the maximum number of game 
numbers has been selected, at block 11 84 the routine may determine whether there are 
a sufficient number of matches between the game niunbers selected by the player and 
the game numbers selected at block 1175 to cause the player to win. The number of 
matches may depend on how many numbers the player selected and the particular 
1 0 keno rules being used. 

If there are a sufficient number of matches, a payout may be determined at 
block 1 186 to compensate the player for wiimmg the game. The payout may depend 
on the number of matches between the game numbers selected by the player and the 
game numbers randomly selected at block 1176. At block 1188, the player's 
1 5 cumulative value or number of credits may be updated by subtracting the bet made by 
the player and adding, if the keno game was won, the payout value determined at 
■block 11 86. The cumulative value or number of credits may also be displayed in the 
display area 1140 (Fig. 29). 

If desired, one or more of the pair of blocks 1158 and 1160 may be added in 
20 other portions of the routine as well. For example, a similar pair of blocks may be 
added between blocks 1 1 56 and 1 1 62. 

Bingo 

Fig. 31 is an exemplary display 1200 that may be caused to be displayed on 
the display unit 170 of one of the gaming units 20 (for example, by a gaming server 

25 52 sending display data to the gaming unit 20) during performance of a bingo routine. 
Referring to Fig. 31, the display 1200 may include one or more video images 1202 of 
a bingo card and images of the bingo numbers selected during the game. The bingo 
card images 1 202 may have a grid pattern. 

To allow the player to control the play of the bingo game, a plurality of player- 

30 selectable buttons may be displayed. The buttons may include a "Cash Out" button 
1204, a "See Pays" button 1206, a "Bet One Credit" button 1208, a "Bet Max Credits" 
button 1 210, a "Select Card" button 1 212, and a "Play" button 1 214. The display 
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1200 may also include an area 1216 in which the number of remaining credits or 
value is displayed. 

Upon activation a button, a corresponding data message may be transmitted 
from the gaming unit 20 to the gaming server 52. The data message may have a 
5 source address that identifies the gaming unit 20 sending the message, a destination 
address that identifies the gaming server 52 to which the message is to be sent, and a 
data field that contams data corresponding to the button, such as wager data, game 
instruction data, etc. 

Similar to the buttons described with reference to Fig. 23, in some 
10 embodiments one or more of the buttons 1 204, 1 206, 1 208, 1 210, 1 212, and 1 214 
may be integrated with a biometric device. For example, the "Play" button may be 
integrated with a biometric device. For instance, the "Play" button may be integrated 
with a biometric device in a similar manner as described with respect to the 
"Deal/Draw" button of Fig. 23. Or, the player may make a "Play" selection by 
15 submitting biometric data via a biometric device. Thus, as described above, 
submitting biometric data may be a mechanism for providing a game play selection 
(e.g., a "Play" selection). Or, biometric data may be submitted in conjunction with 
making the game play selection. 

Fig. 32 is a flowchart of a bmgo routine 1220. The bingo routine 1220 may be 
20 utilized in connection with a single gaming unit 20 where a single player is playing a 
bingo game, or the bingo routine 1220 may be utilized in connection with multiple 
gaming units 20 where multiple players are playing a single bingo game. 

Referring to Fig. 32, at block 1222, it may be determined whether a player has 
requested payoutinfonnation. This may be determined, for example, by detecting 

25 receipt of a "See Pays" data message from the gaming unit 20. If yes, at block 1224 
the routine may cause one or more pay tables to be displayed on tiae display miit 170 
of the gaming unit 20. At block 1226, it may be determined whether a player has 
requested a bet. This may be determined, for example, by detecting receipt of a "Bet 
One Credit" data message or a "Bet Max Credits" data message. If yes, conhrol may 

30 pass to block 1232. 

At block 1232, bet data corresponding to the bet made by tlie player may be 
stored in a memory (for example, the memory of the gaming server controller 401). 
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After the player has made a wager, at block 1234 the player may select a bingo 
card, which may be generated randomly. The player may select more than one bingo 
card, and there may be a maximum number of bingo cards that a player may select. 
At block 1236, the selected card or cards is caused to be displayed on the display unit 
5 170. 

At block 1238, it may be determined whether play of the bingo game is to 
begin. If yes, control may pass to block 1228. At block 1228. biometric data may be 
obtained from the player and checked to see whether it matches that of a registered 
user. For instance, the gaming server 52 may prompt the gaming unit 20 to obtain 
10 biometric data from the user and transmit the biometric data to the gaming server 52. 
The gaming unit 20 may utilize a routine such as routine 620 (Fig. 15) to obtain 
biometric data. Additionally, the gaming server 52 may transmit the obtained 
biometric data to the authentication server 58, and request that the authentication 
server 58 determine whether that biometric data matches biometric data of a 
15 registered user. The authentication server 58 may utilize a routine such as routine 770 
(Fig. 19). hi embodiments that do not include an authentication server 58, the 
determination of whether the biometric data matches biometric data of a registered 
user may be implemented witli another computing device, such as the gaming server 
52, the network computer 22, the gaming unit 20 etc. For instance, the gaming unit 
20 20 may compare the biometric data obtained from the player and compare it to 
biometric data stored on a smart card. 

In another embodiment, at block 122a, operational control may pass from the 
gaming server 52 to the authentication server 58, or to whatever computing system 
that implements block 1228. Then, operational control may pass back to the gaming 
25 ' server 52 at block 1230. 

If the biometric data does match that of a registered user, and, optionally, the 
user identified by the biometric data is permitted to play, control may pass to block 
1240. If the biometric data does not match that of a registered user permitted to play, 
then the routine may end. Prior to ending, a display may be generated which indicates 
30 to the player that he or she has been refiised access to play the game. The display 
may optionally indicate why access was denied. Additionally, instead of ending, the 
routine may branch back to block 1222. 
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As discussed previously, submission of biometric data may be integrated with 
the determination of whether the player desires to "Play." For example, the player 
may submit biometric data in order to request, or when requesting, to "Play." Thus, 
blocks 1238, 1228, and 1230 maybe integrated, their order rearranged, etc. 

5 At block 1240 a bingo number may be randomly generated by the routine. At 

block 1242, the bingo number maybe displayed on the display unit 170 of the gaming 
unit 20 and the display units 170 of any other gaming units 20 involved in the bingo 
game. 

At block 1244, the routine may determine whether any player has won the 
10 bingo game. If no player has won, andtlier bingo number may be randomly selected 
at block 1240. If any player has bingo as determined at block 1244, the routine may 
determine at block 1246 whether the player playing that gaming unit 20 was the 
winner. If so, at block 1248 a payout for the player may be determined. The payout 
may depend on the number of random numbers that were drawn before there was a 
15 winner, the total number of winners (if there was more than one player), and the 
amount of money that was wagered on the game. At block 1250. the player's 
■ cumulative value or number of credits may be updated by subtracting the bet made by 
the player and adding, if the bingo game was won, the payout value determined at 
block 1248. The cumulative value or number of credits may also be displayed in the 
20 'displayareal216(Fig.31). 

If desired, one or more of the pau- of blocks 1228 and 1230 may be added in 
other portions of the routine as well. For example, a similar pair of blocks may be 
added between blocks 1226 and 1232. 

In tiie examples described witii reference to Figs. 23-32, the location of the 
25 gaming unit 20 may optionally be checked, for example using a routine such as 
routine 750 (Fig. 1 8), when the biometric data is checked. 

Game Routines Implemented on Gaming Units 
Although the routines described above with reference to Figs. 23-32 were 
described in the context of being implemented via one or more gammg servers 52, 
30 each of these routines may also be implemented on a gaming unit 20 without a 
gaming server. As an illustration, the poker routine 962 of Fig. 24 will now be 
described in the context of being implemented on a gaming unit 20. One skilled in 
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the art will recognize that other gaming routines may be similarly implemented on a 
gaining unit 20. 

Referring now to Figs. 23 the player selectable buttons 952, 954, 955, 956, 
957, and 958 may be, for example, buttons, buttons displayed on the display unit 170, 
5 etc. Depending on the type of button used, the buttons may be selected by, for 
example, pressing the button, pressing an area of a touch screen display, selecting 
with a mouse, or joystick, etc. Additionally, as described above, submitting biometric 
data may be a mechanism for providing a game play selection (e.g., a "Play" 
selection). Or, biometric data (and optionally location data) may be submitted in 
10 conjunction with making the game play selection. 

Referring to Fig. 24, at block 964, if the player has requested payout 
information, such as by activating the "See Pays" button 955, at block 966 the routine 
may cause one or more pay tables to be displayed on the display unit 170 of the 
gaming unit 20. 

15 At block 968, the player may attempt to make a bet by, for example, selecting 

the "Bet One Credit" button 956. At block 976. bet data corresponding to the bet 
made by the player may be stored in a memory (for example, the memory of the 
gammg unit controller 200). 

At block 978, the routine may determine whether the player has activated the 
20 "Bet Max Credits" button 957. If yes, control may pass to block 980. At block 980, 
bet data corresponding to the bet made by tiie player may be stored in a memory (for 
example, the memory of ttie gaming unit controller 200). 

At block 982, the routine may determine if the player desires a new hand to be 
dealt, (for example, by detecting a selection of the "Deal/Draw" button 958). If yes, 
. 25 then control may pass to blocks 970. At block 970, biometric data may be obtained 
fiom the player and checked to see whether it matches that of a registered user. For 
instance, the gaming unit 20 may obtain biometric data from the user and transmit the 
biometric data to tlae authentication server 58 and request that the authentication 
server 58 determine whether that biometric data matches biometric data of a 
30 registered user. The authentication server 58 may utiUze a routine such as routine 770 
(Fig. 19). In embodiments tliat do not include an authentication server 58, the 
determination of whether the biometric data matches biometric data of a registered 
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user may be implemented with another computing device, such as the network 
computer 22 or the gaming unit 20. For instance, the gaming unit 20 may compare 
the biometric data obtained from the player and compare it to biometric data stored on 
a smart card. 

5 In another embodiment, at block 970, operational control may pass from the 

gaming unit 20 to the authentication server 58, or to whatever computing system that 
implements block 970. Then, operational control may pass back to the gaming unit 
20 at block 972. 

If the biometric data does match that of a registered user, and, optionally, the 
10 user identified by the biometric data is permitted to play, control may pass to block 
984. If the biometric data does not match that of a registered user permitted to play, 
then the routine may end. Prior to ending, a display may be generated which indicates 
■ to the player that he or she has been refused access to play the game. The display 
may optionally indicate why access was denied. Additionally, instead of ending, the 
15 routine may branch back to block 964. 

As discussed previously, submission of biometric data may be integrated with 
the determination of whether the player desires a nejy hand to be dealt. For example, 
the player may submit biometric data in order to request, or when requesting, a new 
hand to be dealt. Thus, blocks 982, 970, and 972 may be integrated, their order 
20 rearranged, etc. 

At block 984, a video poker hand may be "dealt" by causing the display unit 
170 to generate the playing card images 951. After the hand is dealt, at block 986 the 
routine may determine if the player selected a '.'Hold" button 952. If yes, data 
regarding which of the playing card images 951 are to be "held" may be stored in a 
25 memory (for example, the memory of the gaming unit controller 200) at block 388. 

If the user selects the "Deal/Draw" button 958 as determined at block 990, 
each of the playing card images 951 that was not "held" may be caused to disappear 
from the video display 950 and to be replaced by a new, randomly selected, playing 
card image 95 1 at block 992. 
30 At block 994, the routine may determine whether the poker hand represented 

by tiie playing card images 951 currently displayed is a winner. That determination 
may be made by comparing data representing the currently displayed poker hand witli 
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data representing all possible winning hands, which may be stored in a memory (for 
example, the memory of the gaming unit controller 200). If there is a winning hand, a 
payout value corresponding to the winning hand may be determined at block 996. At 
block 998, the player's cumulative value or number of credits may be updated by 
5 subtracting the bet made by the player and adding, if the hand was a winner, the 
payout value determined at block 996. The cumulative value or number of credits 
may also be displayed in the display area 959 (Fig. 23). 

If desired, one or more of the pair of blocks 970a and 972a, 970b and 972b, 
and 970c and 972c may be omitted. Additionally, similar pairs of blocks may be 

1 0 added in other portions of the routine as well. For example, after block 990, biometric 
data could be accessed and authenticated before passing control to block 992. 

Further, altiiough the examples described above were described with reference 
to various flow diagrams, one of ordinary skill in the art will appreciate that many 
other methods may alternatively be used. For instance, various levels of 

15 authentication may alternatively be used. As one example, for small wagers may 
require submission of biometric data corresponding to one fingerprint, whereas Jiurge 
wagers may require submitting finger prints fixjm multiple different fingers, 
submitting to an eye scan in addition to a finger print scan, etc. Also, the order of 
execution ofthe blocks may be changed, and/orsomeoralloftheblocksmaybe 

20 changed, eliminated, or combined. 
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WHAT IS CLAIMED IS: 

1 . An authentication sCTver, comprising: 

a network communications circuit for communicatively coupling to a network; 

a controller that controls the operation of the authentication server, the 
5 controller comprising a processor and a memory operatively coupled to the processor, 

the controller being programmed to receive from a computa: via the 
network a request to determine whether a person is allowed to play a game on 
a gaming system, the request including biometric data associated with the 
person, 

10 ' the controller being programmed to compare the received biometric 

data with data in a database that includes biometric data of persons allowed to 
play games on the gaming system, 

the c ontroUer b emg p rogrammed tod etermine whether t he p erson i s 
allowed to play a game on the gaming system based on the comparison of the 

15 received biometric data with the data in the database, 

the controller being programmed to transmit a message to the computer 
via the network that indicates whether the person is allowed to play a game on 
the gaming System, 

the controller being programmed to determine whether a gaming unit 
20 on which the person desires to play a game is in a permitted location for 

playing the game, 

the controller being programmed to transmit a message to the computer 
via the network that indicates whether the gaming unit on which the person 
desires to play a game is in a permitted location. 

25 

2. An authentication server as defined in claim I, wherein the request to 
determine whether a person is allowed to play a game on a gaming system further 
includes personal data associated with the person; 

wherein the controller is programmed to attempt to retrieve biometric data 
30 fix>m tiie database based on at least some of the personal data; 



wo 2004/095384 PCT/US2004/007844 

66 

wherein the controller is programmed, if biometric data is retrieved from the 
database based on the at least some of the personal data, to compare the received 
biometric data with the biometric data retrieved from the database. 

5 3. An authentication server as defined in claim 1, wherein the controller 

is programmed to query the database based on the received biometric data. 

4. An authentication server as defined in claim 1, wherein the message 
that indicates whether the person is allowed to play a game on the gaming system and 

10 the message that indicates whether the gaming unit on which the person desires to 
play a game is in a permitted location comprise a single message that indicates 
whether the person is allowed to play a game on the gaming unit. 

5. An autiientication server as defined in claim 1, wherein the controller 
15 is programmed to determine w:hether the gaming unit on which the person desires to 

play the game is in a permitted location based on a network address of the gaming 
unit. 

6. An authentication server as defined in claim 5 , wherein the network 
20 address comprises an internet protocol address. 

7. An authentication server as defined in claim 1, wherein the controller 
is programmed to determine whether the gaming unit on which the person desires to 
play the game is in a permitted location based on location data received from the 

25 computer via the network, the location data indicative of the location of the gaming 
unit. 



30 



8. An a uthentication se rver a s d efined i n claim 7 , wherein t he 1 ocation 
data comprises global positioning system data. 
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9. An authentication server as defined in claim 7, wherein the received 
biometric data comprises data associated with at least one fingerprint. 



10. An authentication server as defined in claim 7, wherein the received 
5 biometric data comprises data associated with an eye scan. 

11, An authentication server as defined in claim 7, wherein the received 
biometric data comprises data associated with the person's voice. 



10 12. An authentication server as defined in claim 7, wherein the received 

biometric data comprises data associated with a picture of the person's face. 



13. An authentication server as defmed in claim 1, wherein the game 
comprises a game selected from the group of games consisting of video poker, video 
15 blaclgack, video slots, video keno, and video bingo. 
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14. A method of operating an authentication server, the authentication 
server operatively coupled to a network, comprising: 

receiving fiom a computer via the network a request to determine whether a 
person is allowed to play a game on a gaming system, the request including biometric 
S data associated with the person; 

comparing the received b iometric data with data in a database that includes 
biometric data of persons allowed to play games on the gaming system; 

determining whether the person is allowed to play a game on the gaming 
system based on the comparison of tiie received biometric data with the data in the 
10 database; 

transmitting a message to ttie computer via tiie network that indicates whether 
the person is allowed to play a game on the gaming system; 

determining whether a gaming unit on which the person desires to play a game 
is in a permitted location for playing the game; and 
1 5 ' transmitting a message to the computer via the network that indicates whether 

the gaming unit on which the person desires to play a game is in a permitted location. 

15. A method as defined in claim 14, wherein the request to determine 
whether a person is allowed to play a game on a ganmig system further includes 

20 personal data associated with the person, wherein comparing the received biometric 
data with data in the database comprises: 

attempting to retrieve biometric data firom the database based on at least some 
of the personal data, and 

if biometric data is retrieved fix>m the database based on the at least some of 
25 the personal data, comparing the received biometric data with the biometric data 
retrieved from the database. 

16. A method as defined in claim 14, wherein comparing the received 
biometric data with data in the database comprises querying the database based on the 

30 received biometric data. 
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17. A method as defined in claim 14, wherein the message that indicates 
whether the person is allowed to play the game on the gaming systein and the 
message that indicates whether the gaming unit on which the person deskes to play 

5 the game is in a permitted location comprise a single message that indicates whether 
the person is allowed to play the game on the gaming unit. 

18. A method as defined in claim 14, wherein determining whether the 
gaming unit on which the person desiies to play the game is in a permitted location 

10 comprises determining whether the gaming unit on which tlie person desires to play 
the game is in a permitted location based on a network address of the gaming unit. 

19. A method as defined in claim 18, wherein the network address 
comprises an internet protocol address. 

15 

20. A method as defined in claim 14, wherein determining whether the 
gaming unit on which the person desires to play the game is in a permitted location 
comprises detemining whether the gaming unit on which the person desires to play 
the game is in a permitted location based on location data received from the computer 

20 • via the network, the location data indicative of the location of the gaming unit 

21. A method as defmed in claim 20, wherein the location data comprises 
global positioning system data. 

25 22. A method as defined in claim 14, wherein the received biometric data 

comprises data associated with a fingerprint. 

23. A method as defined in claim 14, wherein the received biometric data 
comprises data associated with an eye scan. 
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24. A method as defined in claim 14, whereia the received biometric data 
comprises data associated with the person's voice. 

3 25. A method as defined in claim 14, wherein the received biometric data 

comprises data associated with a picture of the person's face. 

26. A method as defined in claim 14, wherein the game comprises a game 
selected from the group of games consisting of video poker, video blackjack, video 
10 slots, video keno, and video bingo. 
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27. A ganung server, comprising: 

a network conmnmications circuit that allows data to be commimicated 
between the gaming server and a gaming unit when the gaming unit is 
communicatively coupled to the gaming server via a network; 

5 a controller that controls the operation of the gaming server, the controller 

comprising a processor and a memory operatively coupled to the processor, 

the controller being progranamed to cause first display data to be 
transmitted to the gaming unit via the network communications circuit, the 
first display data representing a game image relating to a game, the game 
10 being playable via the gaming unit that is remote from tlie gaming server, 

the controller being programmed to receive, from the gaming unit, data 
associated with a game play selection of a player; 

the c ontroUer b eing p rogrammed tod etermine w hether t o p ennit the 
game play selection based on biometric data, 

15 the controller being programmed to, if the game play selection is 

permitted, cause second display data to be transmitted to the gaming unit via 
the network conomunications circuit, the second display data representing a 
game outcome image relating to the game. 



20 28. A gaming server as defined in claim 27, wherein the network 

communications circuit allows data to be communicated between the gaming server 
and an authentication server when the authentication server is communicatively 
coupled to the gaming server via the network; 

wherein the data associated with a game play selection of the player comprises 
25 biometric data; 

wherein tiie controller is programmed to transmit tlie biometric data to the 
authentication server via the network conamunications circuit; 

wherein the controller is programmed to receive a message &om the 
authentication server via the network communications circuit, the message indicative 
30 of whether the player is allowed to play the game, the message firom the 
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authentication server in response to the biometric data transmitted to the 
authentication server. 



29. A gaming server as defined in claim 28, wherein the message from the 
5 authentication server is further indicative of whether the biometric data matches 

biometric data of a person allowed to play the game. 

30. A gaining server as defined in claim 28, wherein the biometric data is 
' indicative of the game play selection. 

10 

31. A gaming server as defined in claim 27, wherein the game comprises a 
game selected firam the group of games consisting of video poker, video blackjack, 
video slots, video keno, and video bingo. 



15 32. Agamingserverasdefmedinclami27,whereinthebiometricdata 

comprises data associated with at least one fingerprint. 

33 . A g aming s erver a s d efined i n c laim 2 7, w herein the b iometric d ata 
comprises data associated with an eye scan. 

20 

34. A g araing s orver as defined in claim 2 7, wherein the b iometric data 
comprises data associated with the person's voice. 

35. A g aming s erver a s d efined i n c laim 2 7, w herein t he b iometric d ata 
25 comprises data associated with a picture of the person's face. 



36. A gaming server as defined in claim 27, wherein the controller is 
programmed to determine whether the gaming unit is in a permitted location for 
playing the game; 
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wherein the controller being programmed to determine whether to permit the 
game play selection is further based on whether the gaming unit is in a permitted 
location. 

5 37. A gaming server as defined in claim 36, wherein the network 

communications circuit allows data to be communicated between the gaming server 
and an authentication server when the autlientication server is communicatively 
coupled to the gaining server via the network; 

wherein flie controller is programmed to receive a message firom the 
10 authentication server via the network communications circuit, the message indicative 
of whether the gaming unit is in a permitted location. 

38. A gaming server as defined in claim 37, wherein the data associated 
with a game play selection of the player comprises biometric data; 

15 wherein the controller is programmed to transmit the biometric data to the 

authentication server via the network communications circuit; 

wherein the controller is programmed to receive a message fi:om tlie 

authentication server via the network communications circuit, the message indicative 

of whether the player is allowed to play the game, the message from the 
20 authentication server in response to the biometric data transmitted to the 

authentication server. 

39. A gaming server as defined in claim 38, wherein the message that 
indicates whether the person is allowed to play a game on the gaming system and the 

25 message that indicates whether the gaming unit is in a permitted location comprise a 
single message that indicates whether the person is allowed to play a game on the 
gaming unit. 
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40. A method of operating a gaming server, the gaming server operatively 
coupled to a network, comprising: 

causing first display data to be transmitted to a gaming unit via the network, 
the first display data representing a game image relating to a game, the game being 
5 playable via the gaming unit that is remote firom the gaming server; 

receiving, firom the gaming unit, data associated with a game play selection of 
a player; 

determining whether to permit the game play selection based on biometric 

data; 

10 if the game play selection is pennitted, causing second display data to be 

transmitted to the gaming unit via tiie network, the second display data representing a 
game outcome image relating to the game. 

41. A mettled as defined in claim 40, wherein determining whether to 
1 5 permit the game play selection comprises: 

transmitting the received biometric data to an autlienticatidn server via the 
network; and 

receiving a message fi:om the authentication server via the network, the 
message indicative of whether the playra: is allowed to play the game. 

20 

42. A method as defined in claim 40, wherein the game comprises a game 
selected firom the group of games consisting of video poker, video blackjack, video 
slots, video keno, and video bingo. 



25 43. A method as defined in claim 40, wherein the data associated witli a 

game play selection comprises the biometric data; 

wherein the biometric data is indicative of the game play selection. 
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44. A method as defined in claim 40, wherein the biometric data comprises 
data associated with at least one fingerprint. 

45. A method as defined in claim 40, wherein the biometric data comprises 
5 data associated with an eye scan. 

46. A method as defined in claim 40, wherein the biometric data comprises 
data associated with the person's voice. 

10 47. A method as defined in claim 40, wherein the biometric data comprises 

data associated with a picture of the person's face. 

48. A method as defined in claim 40, fUrther comprising: 

determining whether the gaming xinit is in a permitted location for playing the 
15 game; and 

wherein determining whether to permit the game play selection is further 
based on whether the gaining unit is in a permitted location. 

49. A metiiod as defined in claim 48, further comprising receiving a 
20 message fh)m an authentication server via a network, the message indicative of 

whether the gaming unit is in a permitted location. 

50. A method as defined in claim 49, wherein the data associated with a 
game play selection of the player comprises biometric data, the method fiirther 

25 comprising: 

transmitting tlie biometric data to the authentication server via the network 
communications circuit; and 

receiving a message fi:om the authentication server via the network, the 
message indicative of whether tiie player is allowed to play the game, the message 
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from the axitb.entication server in response to the biometric data transmitted to the 
authentication server. 



51. A method as defined in claim 48, wherein the message that indicates 
5 whether the person is allowed to play a game on the gaming system and the message 
that indicates whether the gaming unit is m a peraiitted location comprise a single 
• message that indicates whetiier the person is allowed to play a game on the gaming 
unit. 
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